Decide whether you need the application tree
Telegram's official Android source is a useful starting point when you need to inspect or modify that application. Our recorded component build answers a much narrower question: whether one Rust component compiled in the supplied sandbox.
On September 17, 2026, our checkout at commit 163356809fa4bd81e64969700753e0a15664a288 measured 1,248.3 MB, 49,719 files and approximately 7,911,420 source lines. These are checkout measurements, not APK size, installed storage, runtime memory or a full-build disk budget.
If you want to create a different interface, compare TDLib. Its README describes a cross-platform Telegram client library that handles network implementation details, encryption and local storage. That makes it a relevant architectural alternative to adopting the application tree, without establishing that either approach will be faster to build or easier for your team.
What our recorded run established
The sandbox configuration recorded 3 CPUs, 12 GB of RAM and image label lab-rust:1. The image label does not establish a Rust compiler version. Commands ran in TMessagesProj/jni/tlottie, not through the Android build system.
The install-labelled step completed successfully in 3.888 seconds, reported as 4 seconds in the stored summary. Its tail shows an index update and multiple crate downloads, including windows-link v0.2.1, foldhash v0.1.5, cfg-if v1.0.4, hashbrown v0.15.5, dlmalloc v0.2.14, libc v0.2.189 and windows-sys v0.61.2. The stored dependency count of 1 cannot describe all those downloads. This step did not demonstrate an installed Telegram application or executable.
The build step completed in 6.937 seconds, reported as 7 seconds. Its output shows tlottie v0.1.0 compiled in the unoptimized development profile, with eight warnings. This was a component compilation, not an Android release build, installed-binary check or measured messaging workload.
The cargo test step exited 101 after 16.582 seconds, reported as 17 seconds. The available tail identifies dos::renderer_rejects_generated_work_after_successful_parse, which panicked when unwrap() received LimitExceeded(ParseMemory). The tail does not establish the underlying cause or an effect on the Android app.
The historical parser stored 482 passed, 2 failed and 484 total. Those figures may double-count the same summary: the raw tail repeats 241 passed; 1 failed before and after a summary marker. Neither set establishes unique, exhaustive counts for the complete command. There is no supported basis for asserting a second distinct failure, a pass percentage or a nearly passing full suite.
The scanner also recorded zero CI workflows, no Dockerfile and no conventional tests directory for the detected target. Those detection results do not establish their absence across the Android repository; the raw log itself includes a test path under src/tests. No Android APK was produced or launched, and no security audit was recorded.
The README's Android setup is separate work
The README at the measured commit specifies Android Studio 2025.1.4, Android NDK 27.2.12479018 and Android SDK 36. It requires cloning with submodules and opening the project in Android Studio rather than importing it.
Its compilation instructions call for a release keystore in TMessagesProj/config, signing values in gradle.properties and project values in TMessagesProj/src/main/java/org/telegram/messenger/BuildVars.java. They also describe two Firebase Android apps, using org.telegram.messenger and org.telegram.messenger.beta, with messaging enabled and a replacement google-services.json.
Telegram says the checked-in dummy keystore, configuration and filled variables support reproducible builds and must be replaced before publishing your own APKs. Our Rust run did not complete or verify this Android setup.
A fork needs its own identity
The README requires your own api_id, asks developers to avoid the Telegram name or make the unofficial status clear, and asks them not to use the standard paper-plane logo. It also instructs developers to publish their code to comply with the licences and to study Telegram's security guidance. These are source-document requirements, not findings from a legal or security audit.
Telegram X is a relevant comparison if you want another complete official Android client. Its source describes a TDLib-based implementation and includes build and reproduction instructions. We did not test it, and its documentation does not justify assuming an easier setup.
Read the ratings within their evidence limits
The scores use a five-point editorial rubric: 1 means substantial documented obstacles or very limited supporting evidence; 2 means significant preparation or evidence gaps; 3 means a documented basis for evaluation with important checks remaining; 4 requires broader corroboration; 5 requires strong evidence across the rated area. Missing evidence lowers confidence, not proof of product quality. These are not benchmark scores.
Setup receives 2/5 because the documented Android workflow requires specific tooling, credentials and signing preparation, while our successful build covered only tlottie. Documentation receives 3/5 because the README gives concrete compilation inputs and publication instructions, but we did not verify the end-to-end workflow. Community receives 2/5 because the supplied extracts do not establish response times or contributor support. Maturity receives 3/5 because this is official application source with documented reproduction provisions, while our run leaves application behavior and release readiness untested.
The supplied release extract identifies 11.4.2 (5469), but does not establish the year or the version at the measured commit. The earlier attribution of 12.10.2 to that commit remains unverified because the commit source could not be retrieved. Neither release labels nor unsupported activity counts should substitute for checking the exact source revision.
Before committing to a fork, follow the pinned Android instructions with your own configuration, build the intended artifact and test the device behavior you depend on. Keep that validation separate from this recorded tlottie result.