# Telegram X: building the source of Telegram's alternative Android client > Telegram X is the official experimental Telegram client for Android, built on TDLib and published under GPL-3.0. This is a review of the repository for engineers who want to build it, fork it, or verify an official APK, not for people looking for a phone app. **TGX-Android/Telegram-X** — The main repository of Telegram X — official alternative Telegram client for Android. - Repository: https://github.com/TGX-Android/Telegram-X - Website: https://play.google.com/store/apps/details?id=org.thunderdog.challegram - Stars: 6,038 · Forks: 1,122 - Language: Java - License: GPL-3.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/tgx-android-telegram-x ## What Telegram X is, and who the repository is actually for Telegram X is described in its README as a slick experimental Telegram client based on TDLib, and as the official alternative Android client for the Telegram messenger. The README frames it around the Telegram API and the MTProto secure protocol, reached through TDLib, whose Android fork lives at TGX-Android/tdlib. The repository is the complete source code plus build instructions, licensed GPL-3.0, with Java as the primary language. The audience is narrow, and that matters. The README's build path targets contributors and builders, not end users. If you want the app on a phone, the README points to Google Play, a beta channel, Huawei AppGallery and GitHub Releases. If you want to change how the client behaves, add a feature, or check that a shipped APK matches the source, you are in the right place. The README even describes what happens after a pull request: once it passes initial review, a special build including your contribution is published in the @tgx_prs channel for community testing, and fixes are pushed as further commits on the same PR. One structural detail is worth noticing before you start: the repository is not a single Gradle module. Alongside app/ and tdlib/ there are tgcalls/, thirdparty/, buildSrc/, reproducible-builds/ and scripts/. The native side is partly pulled in as submodules and partly built by the setup script, which the README says downloads required Android SDK packages and builds native dependencies that are not part of the project's CMakeLists.txt in app/jni/. ## How the client is put together: TDLib, submodules and native third-party code The data flow visible in the repository is the standard TDLib arrangement. The Android app talks to TDLib, which speaks the Telegram API and MTProto, and the README links the TGX-Android fork of TDLib as the dependency. That fork is a submodule, which is why the clone command carries --recursive and --shallow-submodules. Native dependencies are split across two mechanisms. Some are wired through CMake, referenced at app/jni/CMakeLists.txt, and others are vendored under app/jni/thirdparty/ and built by scripts/setup.sh. The README names five of those submodules when it warns about resetting: ffmpeg, libvpx, webp, opus and ExoPlayer. That warning is the useful part: running scripts/reset.sh resets changes inside those submodules, so a local patch to any of them will not survive a reset. The repository also carries a baseline-profile/ directory and a spellchecker.dic, plus version.properties, which is where the build version is presumably read from given the release tags follow a version.build pattern such as v0.29.0.1813. The README does not document the release process itself, so treat the versioning scheme as observable from the release list rather than described. ## Installing the toolchain and producing a first APK The README states three hard prerequisites: at least 5.34GB of free disk space (487.10MB for source, around 4.85GB for files generated after building all variants), 4GB of RAM, and macOS or Linux. Windows is explicitly unsupported for building. On macOS the README asks for Homebrew and a set of tools installed together, and on Ubuntu just git with LFS plus git lfs install for the current user. Start with the macOS prerequisite line as written in the README: ```bash brew install git git-lfs wget gsed && git lfs install ``` On Ubuntu the equivalent is apt install git git-lfs followed by git lfs install. Skipping LFS is the most common way to end up with placeholder files instead of real assets, so run git lfs install before cloning. Clone with submodules in one shot. The README's command is: ```bash git clone --recursive --depth=1 --shallow-submodules https://github.com/TGX-Android/Telegram-X tgx ``` If you forget --recursive, the README gives the recovery path: change into the tgx directory and run git submodule init followed by git submodule update --init --recursive --depth=1. For a production-style build you need signing material. The README instructs you to create a keystore.properties file outside the source tree with four properties: keystore.file (absolute path to the keystore), keystore.password, key.alias and key.password. It also warns to keep the file safe and restrict access to it, suggesting a separate user with home folder encryption for production builds. Then run the setup script and follow its instructions: ```bash cd tgx scripts/./setup.sh ``` The README notes that if you chose a package name different from the one Telegram X uses, you must set up Firebase and replace google-services.json with one suitable for your app.id. After that you can open the project in Android Studio or build from the command line: ```bash ./gradlew assembleUniversalRelease ``` For a development checkout rather than a full build, the README offers a shorter path: clone with --recursive (no depth flags), obtain Telegram API credentials, and create local.properties in the root project folder with the SDK location and credentials. The sample file in the repository is local.properties.sample, and the README shows the keys as sdk.dir, telegram.api_id and telegram.api_hash. ```properties sdk.dir=YOUR_ANDROID_SDK_FOLDER telegram.api_id=YOUR_TELEGRAM_API_ID telegram.api_hash=YOUR_TELEGRAM_API_HASH ``` After that, run scripts/./setup.sh again and build through Android Studio or one of the ./gradlew assemble commands. What you should see is a signed APK under the app module's build output; the README does not name the exact output path, so locate it from the Gradle output. ## Reproducible builds: the part with the strictest constraints The repository ships a reproducible-builds/ directory with a dependencies.txt, and the README explains why: to verify that no additional source code was injected into official APKs, you must reproduce the build on a specific Ubuntu version. That version is not fixed. Ubuntu 21.04 covers builds published before 26th May 2023, Ubuntu 22.04.2 LTS covers builds published before 27th September 2025, and Ubuntu 24.04 LTS covers anything newer. The procedure is prescriptive. Create a user named vk with home directory /home/vk. Clone tgx into /home/vk/tgx. Check out the exact commit you want to verify. If the build included unmerged pull requests, the README says you must follow the actions performed by the Publisher's fetchPr and squashPr tasks, since those are not part of this repository. Then install the dependencies with apt install $(cat reproducible-builds/dependencies.txt) and follow the normal build instructions. Comparison is done with a single command from Android's tooling: ```bash apkanalyzer apk compare --different-only ``` If only signature files and metadata differ, the README considers the reproduction successful. That is a clear success criterion, which is more than many projects offer. The honest part is the TODO list. The README admits the project path must not affect the resulting .so files, so the user and project location requirement could be removed. It notes that native binaries built on macOS have a .comment ELF section that differs from the Linux NDK build. It states that checksums of cold APK builds always differ even with the same keystore and identical inner APK contents, and that the real cause is not yet known. Reproducing builds that include unmerged PRs still depends on an external Publisher repository. The README also says Docker is not considered an option, on the grounds that it hides these tasks rather than solving them. That is a defensible position and a real limitation at the same time: the environment is pinned by hand, not by a container image. ## Where Telegram X is the wrong tool If you need a Telegram client on anything other than Android, this repository cannot help you. The README describes an Android client only. There is no iOS target, no desktop target and no web client in the tree. Searches for Telegram X on PC, on iPhone, or a web login have no answer here. If you are a developer who wants to ship a private messenger quickly, the GPL-3.0 licence and the TDLib dependency set the terms. You inherit a large native build, roughly 4.85GB of generated files, and a signing setup that the README treats as security-sensitive. A small team without a Linux build machine and a keystore story will spend more time on the toolchain than on their own feature. If your goal is to audit an APK you downloaded from somewhere other than the official channels, note that the README's verification path is tied to specific Ubuntu versions and to the exact commit. A build reproduced on the wrong Ubuntu release will differ in ways the comparison command will show, and the README does not promise a clean diff in that case. Finally, if you only want to use Telegram X, none of this matters. The README's first links are the store listings, and the repository exists so that the client can be built and checked, not so that it can be installed from source on a phone by a non-developer. ## Alternatives and how their approach differs The most direct comparison is the main Telegram Android client. Telegram X is positioned in its own README as the official alternative client, experimental in character, and built on TDLib. The mainline client is the default app most users install from the store. The practical difference for a builder is the codebase and the release cadence: Telegram X releases are tagged here, with v0.29.0.1813 on 2026-09-17, v0.28.3.1785 on 2026-01-08 and v0.28.1.1771 on 2025-11-01. The README does not compare the two clients feature by feature, so any claim about which is faster or more complete would be speculation. A second alternative is building directly against the upstream TDLib repository rather than the TGX-Android fork. That gives you the library and its API without the Android client, which suits a backend or a different front end. The cost is that you write the client yourself; Telegram X's value is precisely the Android layer on top, including the native third-party stack under app/jni/thirdparty/. A third path is a third-party Telegram client built on the same public API. Those projects make their own choices about protocol handling and UI, and their build requirements differ completely. If your constraint is a Windows build machine, Telegram X is out of the running before the comparison starts, because the README does not provide Windows build instructions and recommends Linux distributions instead. ## Licence, maintenance and upgrade cost The repository is GPL-3.0. For anyone forking it, that means derivative distributions carry the same licence obligations, and the README's own security advice about the keystore file is separate from that. Nothing here is legal advice; read the LICENSE file in the repository root before you ship anything. On maintenance: the repository is not archived, and the last push was on 2026-09-16, with a release tagged the following day. That is a live project by any reasonable reading of the dates. The README's TODO list for reproducible builds is explicitly marked PR-welcome, which tells you the maintainers expect outside help on the harder parts. Upgrade cost is dominated by the toolchain, not by the application code. Every fresh clone pulls submodules for TDLib, tgcalls and the native libraries, and scripts/setup.sh rebuilds the native dependencies that are outside CMakeLists.txt. The README's disk figure of around 4.85GB for generated files across all variants is the number to plan around. If you carry local patches to ffmpeg, libvpx, webp, opus or ExoPlayer, remember that scripts/reset.sh resets changes inside those submodules, so keep your patches outside the tree or re-apply them after a reset. ## Conclusion Adopt this repository if you need to build, fork or audit the Telegram X Android client and you have a Linux or macOS machine with 4GB of RAM and at least 5.34GB of free disk space; the README states Windows is not supported for building. Do not adopt it if you want a Telegram client for iOS, Windows or the web: this repository contains only the Android client. Before committing, verify that git-lfs is installed and initialized, because the clone depends on it; that scripts/setup.sh completes against your Android SDK; and that you have obtained Telegram API credentials, since a local build without telegram.api_id and telegram.api_hash in local.properties cannot authenticate. If you plan to reproduce a published APK, check the Ubuntu version table in the README against the release date first, because the required version changes per build. ## FAQ ### Which is better between Telegram and Telegram X? The README describes Telegram X as the official alternative Android client for Telegram, built on TDLib, and does not compare the two feature by feature. It presents Telegram X as an experimental client rather than a replacement, so the choice depends on which client's behaviour you prefer. ### How safe is Telegram X? The README states that the repository exists so that public builds can be reproduced and checked for injected source code, using a pinned Ubuntu version and apkanalyzer to compare APKs. That process covers the Android build only; the README does not make claims about the security of the Telegram service itself. ### How do I install Telegram X on Android? The README links Google Play, a beta testing channel, Huawei AppGallery and GitHub Releases as the places to get the app. Building from source is a separate path aimed at developers and requires macOS or Linux, 4GB of RAM and at least 5.34GB of free disk space. ### How do I use Telegram X on Android? The README does not document in-app usage; it covers the source code and the build instructions. The app itself is distributed through Google Play, a beta channel, Huawei AppGallery and GitHub Releases, and the README points there for anyone who wants to run it. ### How do I install Telegram X on a PC? The README describes an Android client only and gives no PC build or install path; the build instructions require macOS or Linux and explicitly do not cover Windows. The only distribution channels listed are Google Play, the beta channel, Huawei AppGallery and GitHub Releases. ## Sources - [License: GPL-3.0](https://github.com/TGX-Android/Telegram-X/blob/main/LICENSE) - [Project website](https://play.google.com/store/apps/details?id=org.thunderdog.challegram) - [README](https://github.com/TGX-Android/Telegram-X/blob/main/README.md) - [Releases](https://github.com/TGX-Android/Telegram-X/releases) - [TGX-Android/Telegram-X on GitHub](https://github.com/TGX-Android/Telegram-X) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tgx-android-telegram-x