Nammu: an Android runtime permission helper kept as a reference

The problem it was built for: permissions revoked behind your back

Nammu exists because Android 6.0 Marshmallow changed how permissions work. Before that, permissions were requested at install time; afterwards they are dynamic, asked only when needed, and revocable by the user at any moment. The README makes the consequence blunt: a user can revoke an essential part of your app and quite probably there will be a lot of app crashes. The Google sample it links to shows the shape of the problem, with a lot happening inside the Activity used to check and grant permissions, and permission rights being checked many times across the code. Nammu's pitch is to remove that ceremony: monitor permissions, check them in the background, and ask for them through a callback. The audience is developers of apps that predate the runtime permission model, or that inherited a scattered permission handling pattern from a team that moved on quickly.

Background monitoring compares the last snapshot with the current state

The monitoring mechanism is a snapshot comparison, and it is simple enough to explain in one sentence. You initialise Nammu with an Application Context, not an Activity Context, then call permissionCompare with a PermissionListener, which compares the list of currently granted permissions against the list captured by the previous call. If you only want to refresh the stored lists without being told whether anything changed, there is refreshMonitoredList for that. The listener callback fires when a permission was changed, removed or added. The README recommends running this comparison on app start, which is the moment a user who revoked a permission is most likely to come back and hit the resulting crash. There is also an ignore list, populated with ignorePermission, so a permission whose changes you do not care about does not trigger the callback. That escape hatch matters, because a permission the system changes on its own would otherwise produce noise.

Asking for a permission through one callback

The request path is where the library removes the most code. Rather than tracking a request id yourself, you call Nammu.askForPermission with an Activity, a permission string and a PermissionCallback, and the callback gives you a success or a fail branch. Because the request id lives inside the library, the code inside your Activity class gets shorter, which is the entire claim in the README. One piece still has to live in your Activity, the callback from the platform, and the README shows it as an override that forwards the request code, permissions and grant results to Nammu.onRequestPermissionsResult. The library also exposes the stored state directly, with getPrevPermissions for the monitored list, getGrantedPermissions for what is currently granted, and a few less important accessors. The design keeps the Activity thin rather than removing it from the flow, which is the compromise it makes with the platform.

JitPack distribution and a Gradle snippet that shows its age

Nammu is distributed through jitpack.io, and the README shows how to add it to a build.gradle:

repositories {
    maven {
        url "https://jitpack.io"
    }
}

dependencies {
    compile 'com.github.tajchert:nammu:1.5.1'
}

Two things in that snippet deserve a second look. The dependency uses the old compile configuration rather than implementation or api, which is what a pre-2018 Gradle setup looked like, so a modern build will need adjusting. And the coordinate names version 1.5.1, while the release list for the repository shows 1.2.1 as the most recent tag, dated 2018-06-10, with the README noting that the last build without AndroidX is 1.2.4 and that Kotlin support arrived in 1.4.0. The project history is therefore: a Java library first, AndroidX added in 1.3.0, Kotlin from 1.4.0, and a Gradle snippet that was never updated. The repository layout matches that history, with a nammu directory for the library, a sample application, and gradle wrapper files at the top level.

The maintenance note is the honest summary of the project

The last push to the repository was on 2026-07-07, and the README closes with a short maintenance section that deserves to be read as the project's own status statement. It says the repository is kept public as a reference for Android runtime permission handling and older app migrations. That is a different claim from actively maintained, and the distinction is the useful one for anyone considering it. The tagged releases stopped in 2018, with 1.2.1 as the last one listed, and the recent push does not come with a new tag in the release history. The most honest way to read this project is as a working piece of reference code for the runtime permission problem, kept visible because the problem still exists in older codebases, rather than as a dependency with a release cadence. That reading also tells you how to evaluate it: read the source, copy what you need, and be explicit about the licence terms you are taking on.

Where the platform has moved past the library

The limitation to weigh is not a bug but an obsolescence. Everything Nammu provides maps onto platform APIs that Android now offers directly, and the project itself points at the Google sample as the current solution. Runtime permissions are requested through the Activity request APIs, results arrive in the standard callback, and the state of a permission can be checked at any point. A library that wraps this can still be worth having, because it centralises the bookkeeping that teams get wrong, but it cannot add capability the platform does not have. There is a second constraint. The monitored permission list is kept in memory by the library, so the comparison model assumes the app process is alive when the check happens, which is exactly the situation the library is designed for but not a guarantee for a process that was killed while the user was in system settings. The README does not discuss persistence, so treat the monitoring as a best-effort check performed on app start rather than a background service that never sleeps.

Editorial conclusion

Nammu fits a team maintaining an older Android app that predates the runtime permission model, where the permission checks are spread across activities and crashes follow a user revoking a permission, and that wants a small library rather than a new architecture. It does not fit a new project, since the platform APIs it wraps are now standard and the repository is described as a reference rather than a maintained dependency. Before adopting it, check that your build still accepts the old compile configuration in the documented Gradle snippet, note that the README mixes a 1.5.1 dependency coordinate with a 1.2.1 release, and read the maintenance note before depending on it in a shipped app.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. tajchert/Nammu on GitHub