# Nnngram is a Telegram client fork with the push notifications removed > NextAlone/Nnngram is a free and open source third-party Telegram client for Android, rebuilt from the official Telegram app source and derived from Nullgram, with FCM push notifications and in-channel ads removed. Building it means replacing the signing key, wiring your own Firebase project and running the Gradle toolchain on Android SDK 36. **NextAlone/Nnngram** — Another gram by NextAlone - Repository: https://github.com/NextAlone/Nnngram - Stars: 526 · Forks: 41 - Language: Java - License: GPL-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/nextalone-nnngram ## A fork of a fork, with the notification path deliberately removed Nnngram is described in the README as Nagram-reborn based on Nullgram, and Nullgram itself is described as a free and open source third-party Telegram client based on the official source code for the Telegram app for Android. So the lineage is: the official Telegram Android client, forked into Nullgram, and Nullgram forked again into Nnngram. The reason for Nullgram is stated plainly in the README. The name is a play on the programming term for an uninitialized, undefined, empty or meaningless value, and the purpose of the name is to express that there is no such bad things in the app. Concretely, the list is: it will not push FCM notifications to your phone, it will not send ads to channels, and it will not compete maliciously or publish malicious rumours about competitors. The FCM point is the one with the most practical consequences. Firebase Cloud Messaging is how a stock Telegram app gets told there is a new message. A client that does not use it has to poll, or connect, and that changes both battery use and notification latency. For a user who wants a client that does not hand Google a push token and does not receive push-driven background wakeups, that is the point of the fork. The repository layout confirms the scale of what has been inherited. `TMessagesProj/` is the main Telegram app module, alongside `TMessagesProj_AppStandalone/`, `TMessagesProj_AppTests/` and `TMessagesProj_Modules/`, plus `buildSrc/`, `libs/`, `Tools/`, `res/`, `apkdiff.py` and `apkfrombundle.py`. There are also `README_CN.md` and `README_JA.md` alongside the English README, and a `crowdin.yml` pointing at Crowdin for localisation, which is how Nullgram and its forks handle translation across dozens of locales. ## Building it means replacing the signature and the Firebase project The compilation guide in the README is a six-step procedure, and three of the steps are about making the build yours rather than the maintainer's. The requirements are Android Studio 2025.1.4, Android NDK 27.2.12479018 and Android SDK 36. You download the Telegram source code, download ccache from ccache.dev and put it in your `PATH`, and replace `release.keystore` in `TMessagesProj/config` with your own. Then you fill in `RELEASE_KEY_PASSWORD`, `RELEASE_KEY_ALIAS` and `RELEASE_STORE_PASSWORD` in `gradle.properties` so the build can reach your keystore. The fifth step is the one that surprises people. You go to the Firebase console, create one Android app with the application id `top.qwq2333.nullgram`, turn on firebase messaging, download `google-services.json`, and copy it into the same folder as `TMessagesProj`. Since this client does not use FCM to deliver notifications, Firebase is present for a narrower purpose, and the README does not explain what that purpose is beyond enabling firebase messaging. The final step builds the APK with `./gradlew assembleRelease`. The consequence of all this is worth stating plainly. Because you replace the keystore and the Firebase application, the resulting APK is signed by you and configured against your own Firebase project. It is not interchangeable with the maintainer's build, and it will not update from the Play Store, since the project has no GitHub releases and the README describes obtaining it from the Telegram channel and from the Play store, with the usual delay for Play store versions. ## The Docker build shows the real module and variant names The repository ships a `Dockerfile`, and it is more informative than the README about how the build is actually structured. The base image is `gradle:8.13-jdk17`, and the environment pins the Android command line tools version, the SDK location under `/usr/local/android-sdk-linux`, the API level at android-36, the build tools at 36.0.0 and the NDK at 27.2.12479018, matching the versions the README asks for. The command line tools are fetched and unpacked by hand, and the SDK licences are accepted non-interactively: ```dockerfile RUN yes | sdkmanager --sdk_root="${ANDROID_HOME}" --licenses RUN sdkmanager \ --sdk_root="${ANDROID_HOME}" \ "build-tools;36.0.0" \ "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" \ "platforms;android-${ANDROID_VERSION}" \ "platform-tools" \ "ndk;${ANDROID_NDK_VERSION}" \ "cmake;3.22.1" ``` The default command is where the variant names surface, and they are not obvious from the README: ```dockerfile CMD mkdir -p /home/source/TMessagesProj/build/outputs/apk && \ mkdir -p /home/gradle/TMessagesProj/build/outputs/bundle && \ mkdir -p /home/source/TMessagesProj/build/outputs/native-debug-symbols && \ cp -R /home/source/. /home/gradle && \ cd /home/gradle && \ gradle --parallel \ :TMessagesProj_App:bundleBundleAfat_SDK23Release \ :TMessagesProj_App:bundleBundleAfatRelease \ :TMessagesProj_AppStandalone:assembleAfatStandalone \ :TMessagesProj_App:assembleAfatRelease \ :TMessagesProj_AppHuawei ``` So the build produces several distinct artefacts in one parallel run: an App Bundle and an APK for the main app, a standalone variant, an SDK 23 release bundle, and a Huawei-specific target. The `afat` naming and the Huawei task suggest deliberate attention to fat APK size and to devices without Google services, which fits a client that strips out the FCM dependency. The Docker image also builds inside `/home/gradle` with sources copied from `/home/source`, which is the usual ccache-friendly layout. ## Contributing means reading the development document first The contribution section is unusually blunt, and the tone is worth reporting as documentation rather than as an instruction to reproduce. For a new feature, the README asks you to make sure you fully understand the development document at `docs/CONTRIBUTING.md`, followed by the instruction to read it if you have not. Then you open a pull request and the maintainer says they should review it in a couple of days. For bugs, the order of operations is prescribed. Install the latest version, since Play store versions usually lag. If the issue also appears in the official Telegram client, report it upstream, and the README is careful about how: do not show Nullgram in the description or screenshots, because the official developers do not like it. Then write the issue in English only, using the issue template, and include the detailed version number, with an emphatic note about writing the version you are actually using. The crash-reporting tip is the concrete one. If the app crashes, you can capture the log with logcat, and the tag to filter on is `Nnngram`. That tag is the fork's own marker, and it is what you would grep for in a bug report. It is also a small reminder of the practical difference from the official client: a fork that renames its log tag has diverged enough that upstream bug reports, upstream crash reports and upstream play store releases all apply only loosely. The repository also carries `BRANDING.md` and a `CLAUDE.md`, which suggests the fork keeps its own branding and identity separate from the upstream project, and a `Dockerfile` plus a `buildSrc/` directory that point to a build that is meant to be reproducible in more than one environment. ## What a fork inherits: the licence, the update path and the app store problem Nnngram is licensed GPL-2.0, inherited with the code it is built on. For a personal build that you sign and sideload, that is not a practical obstacle, since you are not distributing the modified work to others. It becomes one if you redistribute a modified build, which is the normal requirement of a GPL licence and worth knowing before you publish a patched APK rather than keeping it on your own device. The update path is the real cost of the fork model, and the README is direct about it. There are no GitHub releases, so the build artefact comes from the Telegram channel, with the Play store as another distribution route, and Play store versions usually have a delay. Any change to the upstream Telegram app, including a security fix, has to be pulled in and rebuilt by the fork's maintainers before you get it. The bug reporting path is described in a way that also hints at the relationship with upstream. The maintainer asks that upstream-compatible issues be reported to the official developers, without mentioning the fork, which is a reasonable way to avoid drawing attention to the fork but also means the fork's own issue tracker will not necessarily contain the full set of known problems. There is a sponsorship note crediting JetBrains for free open source IDE licences, and the project is reachable through a Telegram channel and a Crowdin project for translations. For a project with this much upstream surface area, the sponsorship arrangement and the translation platform are what keep a fork alive, and they are also the parts most likely to lapse. ## When a fork of a messaging client is the wrong choice There are clear cases where building your own client from the Telegram source is the wrong path, and the reasons are not about ideology. If you need notifications to arrive promptly, removing FCM push is a downgrade rather than a feature. The app then has to hold a connection or poll, and the delivery latency, battery profile and background behaviour all change. The README does not describe the polling interval or the connection strategy, so the practical cost cannot be judged from the documentation. If you need the official app's update cadence and signature, a fork cannot give you that. No GitHub releases exist, the Play store build lags, and any fix has to travel through the fork's maintainers and then through your own rebuild if you are signing with your own key. If you need a stable channel for bug reports, the English-only issue requirement and the upstream-first routing make the fork's tracker a partial view. The version-tag requirement in the issue template suggests the maintainer expects a low volume of well-specified reports. If your concern is privacy in general rather than push delivery and in-channel ads specifically, this fork addresses two narrow things. A dedicated client is a better fit for a threat model where you want to control the whole application rather than tune two behaviours inside a general-purpose one. The build burden is the last honest objection: Android Studio 2025.1.4, NDK 27.2.12479018, SDK 36, ccache in the path, your own keystore, your own Firebase project, and a release build that takes a Gradle run across several variants. ## Conclusion Adopt Nnngram if you want a Telegram client without Firebase Cloud Messaging push delivery and without in-channel ads, and you are prepared to sign the APK with your own key and host your own Firebase project. Do not adopt it if you need a Play Store release with an official signature, an English-first bug report path, or a build that a stranger can reproduce in one command, because the documented build requires your own keystore and Firebase application id `top.qwq2333.nullgram`. Before you start, read `docs/CONTRIBUTING.md`, confirm the `Nnngram` logcat tag works on your device, and check that removing push delivery matches how you actually use Telegram. ## FAQ ### What is Nnngram and what does it change compared to the official Telegram app? Nnngram is a free and open source third-party Telegram client for Android, built from the official Telegram app source and derived from Nullgram. The stated changes are that it does not push FCM notifications to the phone, does not send ads to channels, and does not compete maliciously or publish malicious rumours about competitors. ### What do I need to build Nnngram from source? Android Studio 2025.1.4, Android NDK 27.2.12479018 and Android SDK 36, plus ccache in your `PATH`. You also replace release.keystore in TMessagesProj/config with your own, fill in RELEASE_KEY_PASSWORD, RELEASE_KEY_ALIAS and RELEASE_STORE_PASSWORD in gradle.properties, supply your own google-services.json, and run `./gradlew assembleRelease`. ### Why does building Nnngram need my own Firebase project? The compilation guide asks you to create one Android app with the application id `top.qwq2333.nullgram` in the Firebase console, turn on firebase messaging, download google-services.json and copy it into the same folder as TMessagesProj. The README does not explain what the Firebase project is used for in a client that does not push FCM notifications. ### How do I report a crash in Nnngram? Capture the log with logcat using the tag `Nnngram`, then report it with the exact version number you are running, in English only, using the issue template. If the same issue happens in the official Telegram client, the README asks you to report it upstream as well, without showing the fork in the description or screenshots. ### How do I get a release build of Nnngram? The repository has no GitHub releases. The README points to the Telegram channel and the Play store for builds, and notes that Play store versions usually have a delay, so check the channel for the newest version before reporting a bug. ## Sources - [Issues](https://github.com/NextAlone/Nnngram/issues) - [License: GPL-2.0](https://github.com/NextAlone/Nnngram/blob/main/LICENSE) - [NextAlone/Nnngram on GitHub](https://github.com/NextAlone/Nnngram) - [README](https://github.com/NextAlone/Nnngram/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nextalone-nnngram