DrKLO/Telegram: Building the Official Android Client From Source
Telegram for Android source
At a glance
- What is it?
- The official Telegram for Android source is a GPL-2.0 Java application with a documented reproducible-build path. It is a client, not a server and not a chat library, and the setup steps assume you already have your own api_id, keystore and Firebase project.
- Who is it for?
- Adopt this repository if you are building a Telegram client for Android and can supply your own api_id, release.keystore and google-services.json, because the README states the checked-in versions are dummies for reproducible builds. Do not adopt it if you want a reusable chat SDK, a self-hosted server, or an app you can ship without publishing your own source under GPL-2.0.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 21 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the Repository Actually Is, and Who It Is For
This is the official source code for the Telegram App for Android, written in Java, published under GPL-2.0. The README points at the Play Store listing for org.telegram.messenger, so the code you clone is the same client that ships to users, not a demo or a trimmed sample. The stated audience is developers who want to create applications on Telegram's platform using its API and source code. That framing matters. You are not being invited to extend a framework. You are being handed a finished consumer application and told to make it yours.
The README lists what Telegram asks of every developer in exchange. You obtain your own api_id through core.telegram.org. You do not use the name Telegram for your app, or you make clear that it is unofficial. You do not use the standard logo (the white paper plane in a blue circle). You read the MTProto security guidelines. And you publish your own code to comply with the licences. Those five items are the real scope of the project. If any of them is unacceptable to you, the repository is not a starting point you can negotiate with.
Client Only: The API Surface You Are Not Getting
The README links two external manuals: the Telegram API manuals at core.telegram.org/api and the MTProto protocol manuals at core.telegram.org/mtproto. Both live outside this repository. That tells you where the boundary sits. The repository contains the Android application; the protocol specification and the server behaviour are documented elsewhere and are not part of what you clone. Anyone evaluating this repo as a way to understand MTProto end to end will need those two sites alongside it.
This is also why the project is a poor fit for teams that want a chat layer inside a larger product. There is no documented library boundary here, no published artifact to depend on, and no SDK surface described in the README. The unit of reuse is the application. If you want a messaging component you can drop into an existing Android app, the material gives you nothing to build that on. You would be extracting it yourself from a full client, which is a different and much larger job than adding a dependency.
The Build Path Is Explicit, and It Is Not Short
The README is unusually concrete about tooling. You need Android Studio 2025.1.4, Android NDK 27.2.12479018 and Android SDK 36. Those are pinned versions, not minimums, which is consistent with the reproducible-build goal the README cites. The first command is:
git clone --recursive --shallow-submodules https://github.com/DrKLO/Telegram.git Telegram
The README anticipates the common mistake and gives the recovery command: git submodule init && git submodule update --init --recursive --depth=1. Submodules are load-bearing here, so a plain clone without --recursive leaves you with a tree that will not build.
After cloning, the sequence is: copy your release.keystore into TMessagesProj/config; fill RELEASE_KEY_PASSWORD, RELEASE_KEY_ALIAS and RELEASE_STORE_PASSWORD in gradle.properties; create two Android apps in the Firebase console with application IDs org.telegram.messenger and org.telegram.messenger.beta, enable Firebase messaging, and download google-services.json into the same folder as TMessagesProj. Then open the project in the Studio, with the README's emphasis that it should be opened, not imported. Finally, fill in the values in TMessagesProj/src/main/java/org/telegram/messenger/BuildVars.java, where the README says each variable has a link showing where to obtain the data. The README then states you are ready to compile.
Dummy Credentials and the Reproducible Build Trade-off
The compilation guide opens with a note that deserves more attention than its position suggests. To support reproducible builds, the repository contains a dummy release.keystore, a dummy google-services.json and filled variables inside BuildVars.java. Before publishing your own APKs, you must replace all of them with your own.
This is a deliberate design choice with a sharp edge. Reproducible builds are easier to verify when the inputs are fixed and public, so shipping placeholders makes sense for the project's own release process. For anyone cloning the repo, it means the checkout is pre-configured to build something that is not yours. The failure mode is quiet rather than loud: a build can succeed with the dummy keystore and dummy Firebase configuration, and the problem only surfaces when you try to distribute. There is no separate warning step in the README between compiling and publishing. If you follow the steps in order and stop at 'ready to compile', you have not finished the configuration work.
Licence Obligations and the Update Cadence
The project is GPL-2.0, and the README states the requirement plainly: publish your code too in order to comply with the licences. Combined with the naming and logo restrictions, this shapes what a derived app can look like. You can build and ship a client, but you carry the source publication obligation, and you cannot present it as official Telegram. This is a description of what the repository says, not legal advice; the specific obligations of GPL-2.0 as applied to your distribution are a question for your own counsel.
The release history shows a steady cadence rather than a frozen snapshot. Three releases appear in the material: release-11.4.2-5469 in November 2024, release-11.1.3-5244 in September 2024, and release-11.0.0-5143 in August 2024, each tagged with a version and build number. The repository is not archived. If you fork it, you are forking a moving target, and the cost of staying current is the cost of rebasing your BuildVars.java, gradle.properties, keystore and Firebase configuration against each upstream release. The README does not describe a supported fork or patch workflow, so that reconciliation is work you own.
When a Different Approach Fits Better
If your goal is a messaging feature inside an existing Android application, the realistic alternative is to call the Telegram API directly from your own code, using the API and MTProto manuals the README links, rather than starting from this client. The difference is not one of quality but of unit. This repository gives you a complete application with its own UI, its own build configuration and its own credential requirements. An API integration gives you a protocol to speak and leaves the application structure to you. Choosing this repo means inheriting the application; choosing the API means writing it.
The same distinction applies if you were hoping to run your own messaging backend. Nothing in this material describes server-side code. The repository is the Android client. Self-hosting is not a configuration option here, and the README does not suggest otherwise.
What to Verify Before You Commit to a Fork
Check three things against your own situation before treating this as your base. First, whether you can obtain an api_id and are willing to accept the naming and logo restrictions in the README, since those are stated as requirements for all developers rather than preferences. Second, whether you can replace the dummy release.keystore, the dummy google-services.json and the filled BuildVars.java values with your own, and whether your release process has a step that catches it if you do not. Third, whether the GPL-2.0 publication obligation fits how you intend to distribute.
If all three hold, the repository does what it says: it is the official Android client, buildable with the pinned toolchain the README names. If any of them does not, the mismatch is structural and no amount of build configuration will resolve it.
Editorial conclusion
Adopt this repository if you are building a Telegram client for Android and can supply your own api_id, release.keystore and google-services.json, because the README states the checked-in versions are dummies for reproducible builds. Do not adopt it if you want a reusable chat SDK, a self-hosted server, or an app you can ship without publishing your own source under GPL-2.0. Before your first release build, verify that BuildVars.java, gradle.properties and the two Firebase application IDs all point at your own credentials, and confirm the app name and logo do not imply official status.
Community notes