The 1,248.3 MB checkout is an implementation reference
Our measured DrKLO/Telegram checkout occupied 1,248.3 MB and contained the official Android client, rather than a compact kit for adding Telegram chat to another app. You get the production interface, protocol integration, media code, and native components that Telegram ships on Android. That makes the repository useful for tracing how the client behaves. A fork also inherits its branding boundaries, release machinery, and native surface.
Scale changes the decision before Android Studio even opens. We measured 49,719 files and about 7,911,420 lines of source at commit 1633568. The root project is mainly Java, while native directories and recursive submodules pull in other toolchains. A developer who only needs Telegram connectivity should compare TDLib before adopting an entire application tree.
A publishable fork needs two Firebase apps and its own identity
On our 49,719-file checkout, the README requires 2 Firebase Android apps before a fork is ready to publish. You must also obtain your own Telegram api_id, provide a release keystore, place its passwords in gradle.properties, and fill the variables in BuildVars.java. The Firebase apps use org.telegram.messenger and org.telegram.messenger.beta, with messaging enabled and a replacement google-services.json.
Those requirements sit on top of a recursive clone. The named toolchain is Android Studio 2025.1.4, Android NDK 27.2.12479018, and Android SDK 36. Telegram says to open the project in Studio rather than import it. Missing the recursive clone leaves required submodules absent, although the README gives recovery commands.
What happened when we ran it
Our measurement setup was an unprivileged container with 3 CPUs and 12 GB of RAM, where we cloned commit 1633568. The sandbox installed the detected Rust package in 4 seconds and built it in 7 seconds. Cargo ran inside TMessagesProj/jni/tlottie, a submodule pinned by the Android repository. The install added 1 package for this target. We did not produce or launch the Android APK.
Our cargo test run ended with exit code 101 after 17 seconds. Across the measured commands, Cargo reported 482 passed and 2 failed out of 484. The log tail identifies dos::renderer_rejects_generated_work_after_successful_parse as one failure. It panicked after unwrap() received LimitExceeded(ParseMemory). The tail does not name the other failed test or establish why either result occurred.
The distinction matters because tlottie is the Rust renderer for Lottie animations, not the whole messenger. Its manifest exposes native, C API, WebAssembly, and reduced-standard-library feature paths. Passing 482 tests gives useful evidence for that component's exercised cases. It says nothing direct about login, message sync, notifications, media capture, database upgrades, or APK signing.
Our scanner found 0 CI workflow files, no Dockerfile, and no tests directory for the detected Rust target. Cargo still discovered and ran 484 tests. A conventional folder check can miss real coverage, while a successful component build can miss the application above it. Treat the lab result as a narrow source check, not a replacement for device tests and a signed release build.
The licence and branding rules affect the product
For this 1,248.3 MB source tree, Telegram's README gives third-party publishers 3 visible identity duties: use a separate API ID, avoid the Telegram name or clearly label the app unofficial, and avoid its standard logo. It also tells developers to study the MTProto security guidance and publish their source to comply with the licences. A company that wants a closed Android derivative should get legal advice before building around this code.
The 7,911,420-line source count also makes privacy review a continuing job. A new publisher owns its Firebase setup, signing key, BuildVars.java values, and treatment of user data. The dummy keystore, filled variables, and sample google-services.json support reproducible builds. Telegram says to replace them before publishing.
A 2026 push outweighs the older GitHub release tag
GitHub recorded the last push on September 16, 2026, and commit 1633568 updated the source to 12.10.2. The repository had 29,881 stars and 559 combined open issues and pull requests when fetched. Its Issues feature was disabled, while open pull requests showed current activity, including a paging fix submitted on September 17.
The latest GitHub release page was still 11.4.2 from November 20, 2024. That gap is not evidence that development stopped, because the 2026 push and current pull requests show the opposite. The Releases tab is a poor guide to the version on master. Pin the commit you audit, keep its submodule revisions, and reproduce the signed artifact against that source.
Use the official tree when the official tree is the requirement
The 4-second Rust install and 7-second component build support choosing DrKLO/Telegram for contribution work, source inspection, reproducibility checks, or a fork that begins with Telegram's Android interface. They do not shrink the surrounding app. A production fork still needs the Android stack, service credentials, device coverage, signing controls, source publication, and distinct identity.
For a new client with a different interface, TDLib removes much of the inherited Android application surface while keeping Telegram client plumbing. Telegram X is the closer comparison if you want another official Android implementation. Adopting this repository means owning 49,719 files and their release obligations, even though the native slice we tested nearly passed its 484-test run.