KPermissions asks for Android runtime permissions through one builder

The problem it removes

KPermissions is described as an Android library totally written in Kotlin that helps to request runtime permissions, and the second sentence is the interesting one: it is compatible also below Android M, API 23, where runtime permissions do not exist, so you have not to handle them separately.

That is the whole argument. The platform API for runtime permissions arrived in Android 6.0, so an app that supports older versions has to branch: on modern versions you call the request API and get a callback, and on older ones you simply proceed because the permission is granted at install time. That branch is the source of a class of bugs where a permission is requested on one path and assumed on another.

KPermissions folds the two paths into one call, so the version check lives in the library rather than in every screen that needs a permission.

The rest of the feature set is about how you receive the answer rather than how you ask the question. The result can come back as a callback, as a suspend function, as a Flow, as an RxJava observable, or as LiveData, and the library ships separate artifacts so you only take the reactive model you actually use.

The compatibility floor is a minimum API level of 14, the same as the latest support libraries, and the library requires AndroidX, with the note that to use it in a project without AndroidX you should refer to version 1.x.

The project is Kotlin, licensed Apache 2.0, with the releases KPermissions 3.5.0 from 2024-02-22, 3.4.0 from 2022-11-11 and 3.3.0 from 2021-12-18, and the last push on 2026-09-23.

The builder and the result

The core API is an extension method, `permissionsBuilder()`, which you can call from an Activity or a Fragment, and the request is built and sent in one chain:

// Build the request with the permissions you would like to request and send it.
permissionsBuilder(Manifest.permission.CAMERA, Manifest.permission.SEND_SMS).build().send { result ->
    // Handle the result, for example check if all the requested permissions are granted.
    if (result.allGranted()) {
       // All the permissions are granted.
    }
}

Three things are worth reading in that. The permissions are the ordinary `Manifest.permission` constants, so there is no separate abstraction to learn. The build and send are separate steps, `build()` produces a request and `send()` dispatches it, which is what makes the request reusable across the different consumption styles later. And the result object has an `allGranted()` helper, so the common case is one call rather than a loop over the permissions.

The `send { }` form takes a callback, and the result arrives once the user has answered, whether they granted everything, granted some, or denied.

The README points at two places for the rest. The wiki is where you discover all the APIs, and it is said to contain useful notes and advanced features not explained in the README. And there is a sample project provided by the library, which shows how to integrate it and request the permissions from an Activity or a Fragment.

Four ways to consume the same result

The design decision that makes this library more than a convenience wrapper is that the result object is a first class thing with several adapters, and each reactive model gets its own artifact so you do not inherit a dependency you do not use.

The coroutines artifact, `kpermissions-coroutines`, adds the integration with the Kotlin coroutines:

launch {
    val result = permissionsBuilder(Manifest.permission.CAMERA).build().sendSuspend()
    // Handle the result.
}

It also supports the Kotlin coroutines Flow API:

val request = permissionsBuilder(Manifest.permission.CAMERA).build()
launch {
    request.flow().collect { result ->
        // Handle the result. 
    }
}
request.send()

The Flow form is the interesting one. Note that `send()` is still called, and the flow emits the result to the collector. That shape works well when the result can change over the life of the request, for example if the user revokes a permission in settings and the app returns to the foreground, and it lets a screen keep a single long-lived collector rather than re-subscribing after every configuration change.

The artifacts `kpermissions-rx2` and `kpermissions-rx3` add the RxJava integrations:

val request = permissionsBuilder(Manifest.permission.CAMERA).build()
request.observe().subscribe { result ->
    // Handle the result.
}
request.send()

And in the core artifact there is a useful extension on `PermissionRequest` to get a LiveData:

val request = permissionsBuilder(Manifest.permission.CAMERA).build()
request.liveData().observe(this) { result ->
    // Handle the result.
}
request.send()

That the LiveData support lives in the core artifact while the other two need extras tells you something about how the author expects the library to be used. LiveData is tied to the Android lifecycle and to AndroidX, and so is the library, so it costs nothing to include. Coroutines and RxJava are choices about your application architecture, and those are paid for separately.

The artifacts and how to add them

The Gradle snippet is the whole installation story:

dependencies {
    // The core artifact.
    implementation 'com.github.fondesa:kpermissions:x.x.x'
    // If you want the extensions for RxJava 2.
    implementation 'com.github.fondesa:kpermissions-rx2:x.x.x'
    // If you want the extensions for RxJava 3.
    implementation 'com.github.fondesa:kpermissions-rx3:x.x.x'
    // If you want the extensions for the Kotlin coroutines.
    implementation 'com.github.fondesa:kpermissions-coroutines:x.x.x'
}

The group is `com.github.fondesa`, and the version placeholder in the README is `x.x.x`, which you replace with the version you want from Maven Central, where the project is published. You can also download a jar from the GitHub releases page if you are not using Gradle.

The repository layout confirms the module structure. There are directories for `kpermissions`, the core, and for `kpermissions-coroutines`, `kpermissions-rx2`, `kpermissions-rx3` and `kpermissions-testing`, the last being a module for testing code that needs to exercise permission behaviour.

That testing module is worth a moment. Permission flows are hard to test because the answer comes from a system dialog, so a library that offers a way to drive the result in tests saves the usual arrangement of an interface you can substitute, and the module is a sign that the author thought about that.

The rest of the repository is standard Android project furniture, with `build.gradle`, `settings.gradle`, `gradle.properties`, `gradlew` and `gradlew.bat`, a `build-tools/` directory, a `ci/` directory, `codecov.yml`, `renovate.json` for dependency updates, an `android-config.properties` file and a `sample/` directory with its own build file and sources.

Where it sits against the platform API

The alternative to this library is the platform API, and the difference is worth spelling out rather than leaving as a general preference.

The raw approach is `ActivityCompat.requestPermissions` with a request code, and a callback delivered to the Activity or Fragment, which you then route to the right place by comparing the request code. It works, it is in the framework, and it adds no dependency.

What it does not do is handle the pre-Marshmallow case, so a codebase supporting API 21 has to branch on the SDK level at every call site, and the branch is easy to get wrong in the other direction too, for example by requesting a permission that does not exist on old versions. It also gives you a single callback per activity rather than a per-request result, so concurrent permission requests need their own bookkeeping.

KPermissions replaces all of that with one builder and one result object, at the cost of a dependency, and the dependency comes with a requirement: AndroidX.

The second alternative is to not request at all at the point you need the feature. Asking for a permission when the user taps the feature that needs it, rather than at launch, is both better practice and a common design, and in that case the value of a permission library shrinks to the convenience of the callback.

The maintenance point deserves a mention too. The most recent published release is 3.5.0 from February 2024, while the last push to the repository was on 2026-09-23. That gap means the work is either landing on the branch without a release yet, or the project is being maintained sporadically. Either way, if you take this dependency, pin a released version and treat the master branch as something to look at rather than something to depend on.

Editorial conclusion

Adopt KPermissions if you maintain an Android codebase that still supports versions below API 23, or if you want a single result callback across coroutines, RxJava and LiveData without writing the plumbing for each. Do not adopt it for a new project that only targets recent Android versions, since the platform API is small and the library's value is mostly the version handling. Verify first that the artifact you take matches the AndroidX status of your project, since the README says the library requires AndroidX and points non-AndroidX projects at version 1.x, and that you are on a release rather than the master branch, since the most recent published release is 3.5.0 from 2024-02-22 while the last push was on 2026-09-23.

Frequently asked questions

Official sources

1. fondesa/kpermissions on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases