# NagramXF: a Telegram Android fork with the extra features people keep asking for

> NagramXF is a Java fork of the Nagram X Telegram client that pulls in features from exteraGram and AyuGram, distributed as signed APKs rather than through a package manager. The judgment is that it is a competent build of someone else's app that you assemble yourself, and the cost of that choice is credential setup and an unspecified upstream.

**Keeperorowner/NagramXF** — A fork of NagramX with additional features.

- Repository: https://github.com/Keeperorowner/NagramXF
- Stars: 1,027 · Forks: 69
- Language: Java
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/keeperorowner-nagramxf

## A fork of Nagram X that merges features from two other clients

The README states the whole proposition in one line: NagramXF is a fork of Nagram X with additional features, and it includes most features from exteraGram and AyuGram. The acknowledgements list five upstreams in total, naming NagramX, AyuGram, Cherrygram, exteraGram and OctoGram, which tells you the feature set is assembled from several independent Android Telegram clients rather than invented in one place.

The audience is narrow and obvious. These are unofficial Android Telegram clients, distributed outside the Play Store, and the people who install them are the ones who want options the official client does not expose. The fork is written in Java, which fits a project that descends from an existing Android app rather than starting over, and the repository root has the shape of a Gradle Android project: build.gradle, settings.gradle, gradle.properties, buildSrc, gradlew, the TMessagesProj module, a separate TMessagesProj_AppTests module, and a Tools directory.

The default branch is dev, and the licence is GPL-3.0. That licence has a direct consequence for anyone thinking of shipping this in a product: the code you take from here carries copyleft obligations, and the project itself is a client application rather than a library, so the realistic uses are personal builds and community distribution rather than embedding.

## Clone with submodules, or the build will not start

The compilation guide is short but the order matters. The first step is to clone the repository with its submodules:

```bash
git clone --recursive --shallow-submodules https://github.com/Keeperorowner/NagramXF.git NagramXF
```

If you already cloned without them, the guide gives the repair command:

```bash
git submodule update --init --recursive --depth=1
```

The presence of a .gitmodules file at the repository root and of an sdk_pysrc/ directory suggests the submodules carry native and script sources that the Gradle build expects to find in place. Skipping them produces a project that opens in Android Studio and then fails during configuration, which is the classic first mistake here.

The build itself is a standard Android Studio flow. The last step of the guide is to open the project in Android Studio and start building, with gradlew and gradlew.bat also present in the root if you prefer the command line.

## local.properties holds four values the build will not have otherwise

Step two is where the difference between cloning and building becomes clear. You have to obtain API credentials, TELEGRAM_APP_ID and TELEGRAM_APP_HASH, from the Telegram Developer Portal, and then create a local.properties file in the project root containing them:

```bash
TELEGRAM_APP_ID=<your_telegram_app_id>
TELEGRAM_APP_HASH=<your_telegram_app_hash>
```

Those are key and value pairs in a properties file, shown here as a bash block because the file format itself is plain key equals value lines. The point worth internalising is that a build of this client is personalised: it is signed to your Telegram application identity, and a build assembled with somebody else's app ID is a build that talks to Telegram as them.

Step three adds the signing material, and this is the part that separates a usable APK from a debug artifact. The guide says to replace release.keystore with your own keystore and add signing configuration to local.properties, with these keys:

```bash
KEYSTORE_PASS=<your_keystore_password>
ALIAS_NAME=<your_alias_name>
ALIAS_PASS=<your_alias_password>
```

The two credentials and the three signing values all live in the same untracked local.properties file, which is the correct arrangement since it keeps secrets out of version control, but it also means the build is not reproducible for anyone who does not have your file.

## Three project specific values that no build step can guess

Beyond credentials, the guide lists three substitutions that are specific to this fork and are the most likely source of a broken or half working build.

For FCM support, you replace TMessagesProj/google-services.json with your own configuration file. That file is what Firebase Cloud Messaging uses, so without a valid one the push notification path in the app has nothing to talk to.

For maps, you set your Google Maps API key in the com.google.android.maps.v2.API_KEY meta-data entry in TMessagesProj/src/main/AndroidManifest.xml. This is an edit in the manifest rather than in a properties file, which means it is a source change, and it is the kind of edit that will show up in a diff if you are careless about leaving it in.

For the remote helper, you set BaseRemoteHelper.CHANNEL_METADATA_ID in TMessagesProj/src/main/java/tw/nekomimi/nekogram/helpers/remote/BaseRemoteHelper.java to your metadata channel's numeric ID, without the -100 prefix. The path tells you this fork keeps its own helper class for remote metadata, and the -100 detail is the kind of convention that produces a channel that silently never resolves if you get it wrong. None of these three values has a documented default, so a build that skips them is a build with visible gaps.

## Installs come from Telegram channels and GitHub releases

The download section is where this project differs most from a normal library, and it is worth reading carefully if your policy forbids unofficial binaries. There are three sources: a Telegram Channel, a Telegram Beta Channel, and GitHub Releases. The project also lists sponsorship links on two platforms.

So there are two distinct consumption paths, and they are not equivalent. A user who does not want to compile anything takes an APK from the channel or from the release page. A user who wants their own API credentials, their own signing key, and their own map configuration clones and builds, which is the path the compilation guide describes.

The release list shows three tagged builds, 1249 at 12.9.2.1249 on 2026-08-24, 1450 at 12.10.1.1250 on 2026-09-03, and 1251 at 12.10.1.1251 on 2026-09-14. The tag numbers and the internal version strings do not line up in an obvious order, 1450 sitting between two 12xx tags, so treat the tag as the identifier to pin and the parenthesised string as the app's own version, not the other way round. The repository is not archived and the last push was on 2026-10-15.

## The reverse engineering notice is a real term to read

The README carries a Notice that says the project reverse engineered and uses some code from closed source projects, and that the original developers are listed as contributors for the functionality obtained that way. It is stated plainly rather than buried, which is unusual and worth respecting.

What this means practically is a licensing question you cannot answer from the GPL-3.0 file alone. The repository's own licence covers the code in the repository, and the notice says some behaviour comes from closed source projects through reverse engineering. Whether that is permissible is a question for whoever ships the app, not for this project, and no legal advice is implied here. What is concrete is that the provenance of some features is not traceable to a public source tree, which makes auditing harder than it would be for a clean fork.

There is a second reason to read the notice: the fork inherits upstream obligations as well. The acknowledgements show this project sits in a chain of clients. When upstream changes, the fork has to absorb the change, and the GPL-3.0 terms apply to anything you distribute from the result.

## Conclusion

NagramXF makes sense if you want a Telegram client with the extra features these forks collect and you are willing to compile it yourself with your own Telegram API credentials, a keystore, and a Google Maps key. It does not make sense if you want a supported, signed, auto updating app from a store, or if you cannot supply credentials for a client that talks to Telegram on your behalf. Before you start, read the Notice section in the README about reverse engineered code from closed source projects, check that your own Telegram app ID and hash are available, and remember that the default branch is dev while the published builds are tagged releases, so decide which you are actually installing.

## FAQ

### How do I build NagramXF from source?

Clone the repository with its submodules using git clone --recursive --shallow-submodules, create a local.properties file with TELEGRAM_APP_ID and TELEGRAM_APP_HASH, add your keystore values, and open the project in Android Studio. The README lists replacing TMessagesProj/google-services.json and the Google Maps API key entry as further required steps.

### Where can I download NagramXF APKs without compiling it myself?

The README lists three download sources: a Telegram channel, a Telegram beta channel, and the GitHub Releases page for the repository. Tagged builds include 1251 at 12.10.1.1251 published on 2026-09-14.

### What is the difference between NagramXF and Nagram X?

NagramXF describes itself as a fork of Nagram X with additional features, including most features from exteraGram and AyuGram. The acknowledgements also credit Cherrygram and OctoGram, and the repository is licensed under GPL-3.0.

## Sources

- [Issues](https://github.com/Keeperorowner/NagramXF/issues)
- [Keeperorowner/NagramXF on GitHub](https://github.com/Keeperorowner/NagramXF)
- [License: GPL-3.0](https://github.com/Keeperorowner/NagramXF/blob/dev/LICENSE)
- [README](https://github.com/Keeperorowner/NagramXF/blob/dev/README.md)
- [Releases](https://github.com/Keeperorowner/NagramXF/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/keeperorowner-nagramxf
