Nullgram: a Telegram Android client built without push notifications

What the fork changes relative to the official Android app

Nullgram is described as a free and open source third-party Telegram client based on the official source code for the Telegram App for Android. That relationship defines both what the project is and its limits, since the protocol, the server side and the bulk of the feature set come from upstream.

The stated motivation is a list of things the client will not do. The name is explained first: null is used in programming for an uninitialized, undefined, empty or meaningless value, and the purpose of the name is to express that there are no such bad things. Specifically, the project says it will not push FCM notifications to your phone, will not send ads to channels, and will not compete maliciously or publish malicious rumours about competitors.

The first of those is the substantive engineering change, because it alters how the client receives updates rather than merely what it displays. A client that does not receive push notifications has to check for new messages by polling, and that is a real behavioural difference in battery use and in how promptly messages appear. The project does not document the polling mechanism, so the exact implementation is not something the documentation confirms.

This is a client, not a library. There is no API for other developers to consume, and the topics are simply android and telegram.

Where the releases come from and how the versions are named

Nullgram distributes through its own Telegram channel and the Play Store, and the contribution guidance notes that Play Store versions usually have a delay, so checking the channel is the faster route to the newest build.

The version naming is unusual and worth understanding before you compare builds. The release tags are of the form v11.13.0-05eecdb, where the suffix is a commit hash. The most recent listed are v11.13.0-05eecdb from 2025-07-06, v11.12.0-3d76896 from 2025-06-05 and v11.8.2-e3fa787 from 2025-03-23. The upstream version prefix tells you which Telegram release the fork is based on, and the hash suffix identifies the exact fork commit, which matters when two people report different behaviour on what looks like the same version.

The last push to the repository was on 2026-10-19, so commits continue on the master branch well after the last tag, and the repository is not archived. Translations are handled through Crowdin, and the README exists in Chinese and Japanese alongside English.

Building the app from source

The compilation guide sets out the toolchain requirements, which are Android NDK rev. 21 and Android SDK 14. The steps then walk through preparing a signing key, registering a Firebase application, fetching submodules and running Gradle.

The Firebase step is the one with a hard requirement in it. You create one Android app in the Google Cloud console with the application ID top.qwq2333.nullgram, turn on firebase messaging, and download google-services.json, which is copied to the same folder as TMessagesProj. The credentials for your own release keystore are supplied through RELEASE_KEY_PASSWORD, RELEASE_KEY_ALIAS and RELEASE_STORE_PASSWORD in local.properties, and release.keystore in TMessagesProj/config is replaced with your own.

Submodules are checked out with a command that deliberately skips one of them:

git -c submodule."libs/rust".update=none submodule update --init --recursive

The build itself is a single Gradle invocation:

./gradlew assembleRelease

Note the pairing with the previous step: the libs/rust submodule is excluded from that update, which means the Rust sources it holds are not fetched by the documented command, so the build environment has to be arranged accordingly.

The container image that builds all four APK variants

The repository carries a Dockerfile that reproduces the toolchain in a container, which is the fastest way to see whether the build works on a machine that is not otherwise set up for Android.

The base image is gradle:8.7.0-jdk17, and the image installs the Android command line tools, the platform tools, the build tools and the NDK itself:

FROM gradle:8.7.0-jdk17
ENV ANDROID_SDK_URL https://dl.google.com/android/repository/commandlinetools-linux-7302050_latest.zip
ENV ANDROID_API_LEVEL android-35
ENV ANDROID_BUILD_TOOLS_VERSION 35.0.0
ENV ANDROID_HOME /usr/local/android-sdk-linux
ENV ANDROID_NDK_VERSION 21.4.7075529
ENV ANDROID_VERSION 35
ENV ANDROID_NDK_HOME ${ANDROID_HOME}/ndk/${ANDROID_NDK_VERSION}/

The last part of the file is what makes the image useful, since it runs four Gradle targets in sequence to produce the release variants:

gradle :TMessagesProj_App:bundleBundleAfat_SDK23Release && \
gradle :TMessagesProj_App:bundleBundleAfatRelease && \
gradle :TMessagesProj_AppStandalone:assembleAfatStandalone && \
gradle :TMessagesProj_App:assembleAfatRelease

Two variants are app bundles and two are assembled APKs, and the image is built around a source directory copied into a Gradle home directory. There is also a curious step in the image, where the dx binary and lib/dx.jar are copied from build-tools 30.0.3 into the 35.0.0 directory, which suggests the upstream build still expects those legacy tools to be present.

How to report a bug that also affects the official client

The contribution guide is unusually specific about bug reports, and the reason is a fork relationship rather than a technical one.

The first step is to make sure you have the latest version installed, and to check the channel, because Play Store versions usually lag. Then, if the issue appears in the official Telegram client too, the guidance is to submit it to the officials, with an explicit warning not to show Nullgram in the description or screenshots, since the official developers do not like the fork. That is a blunt instruction, and it tells you something about the working relationship the project has with upstream.

For the fork's own tracker, the requirements are strict: write the issue in English only, use the issue template, give the detailed version number, and use logcat to capture a crash log with the tag Nullgram. The guide is unusually blunt about the one thing it will not accept, which is a report that says only that the latest version was used.

For new features, the path is to read docs/CONTRIBUTING.md in full first, then open a pull request, with review expected within a couple of days.

GPL-2.0 terms and what a fork of a closed client implies

The repository is licensed under GPL-2.0, with the licence file at the root. For an end user installing an app binary that is largely a fair reading, since you are not distributing the code.

For anyone who does distribute it, or who forks Nullgram in turn, the terms are more demanding, because the project is a derivative of the official Telegram App for Android source and the GPL obligations attach to the combined work. That is a question for your own counsel rather than something the repository answers, and the documentation does not discuss relicensing or exception grants.

There is a second constraint that is not legal but is just as binding in practice. The upstream Telegram protocol and the app's own feature set move constantly, and the fork's version tags show the upstream prefix advancing while the fork commit suffix changes. Building from master gives you whatever the fork has merged, and the gap between the last tag and the current master is where unreviewed work lives. A user who wants a known state should install a specific tagged build rather than track the branch.

The project also links to a Telegram channel, a Crowdin translation project, a group for bug reports and a Play Store listing, which together describe a project that is actively shipping to end users.

Editorial conclusion

Adopt Nullgram if you want a Telegram client for Android that does not push FCM notifications to your phone and you are willing to install a build outside the Play Store or from a channel release, since a fork of a closed-protocol client is always a rolling rebuild. Do not adopt it if you need a maintained Play Store listing with timely updates, if you depend on the official client features the fork does not carry, or if the GPL-2.0 terms do not suit your distribution model. Before building it yourself, confirm the Android NDK revision 21 and SDK 14 requirement against your toolchain, register your own Firebase application with the application ID top.qwq2333.nullgram so that the build can produce a google-services.json, and check that the release keystore you substitute in TMessagesProj/config is one you control.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. qwq233/Nullgram on GitHub
4. README
5. Releases