PermissionsDispatcher 4.x: A bunch of stuff

December 25, 2018 android oss lang-en

From July of this year we’ve been adding/removing a bunch of stuff to/from PermissionsDispatcher 4.x(the latest is 4.2.0 for now). I’m personally honored that there’re no changes which break backward API compatibility at all, but some of the changes are not trivial and supposed to be recognized to let you build a reliable and substantial runtime permissions grant flow in your application. In this article I’ll go through some significant changelog topics respectively in minutes.

AndroidX support


Most importantly we’ve started off supporting AndroidX in favor of Android Jetpack components advent. Hence to upgrade PermissionsDispatcher to 4.x from previous versions you have to complete AndroidX migration in your application beforehand.

Drop support


Related to the AndroidX support mentioned above we simultaneously dropped support as it has been deprecated.

Drop Xiaomi support


Xiaomi is the thing that we’ve been seriously struggling with for years. Originally we decided to add a dedicated workaround for Xiaomi since they customized Android framework permission mechanism and the presented code on Android Developers didn’t work well as expected. But reportedly recent Miui(OS on Xiaomi) has revised their customization and we don’t need to puzzle over it anymore! We strongly believe that our decision is for the right direction but also recommend you to test your app behavior on several physical Xiaomi devices if a percentage of the device is unignorable. Note that this change is from 4.1.0.

Incremental annotation processing


Gradle 4.7 introduced incremental annotation processing and seemingly some popular libraries have started supporting the feature like Dagger2 has done. Likewise PermissionsDispatcher supports the incremental processing to make build time faster from 4.2.0! Although be sure to note that the feature is only for Java because kapt hasn’t supported incremental annotation processors yet. For more detail check YouTrack link below.


Flexible OnShowRationale handling


We’ve got a feedback that current OnShowRationale annotated method signature is sort of hard to handle especially with DialogFragment since parameter’s type PermissionRequest is not serializable. After a few discussions we decided to change API as below(don’t worry we keep a backward compatibility) from 4.2.0.

Consequently if you want to show DialogFragment in OnShowRationale annotated method, it can be done easily! Here’s a minimum example.

    class MainActivity : AppCompatActivity() {
        fun showCamera() {

        fun showRationaleForCamera() {

Then processor will generate processShowCameraPermissionRequest and cancelShowCameraPermissionRequest as extension methods. Utilize them as appropriate in DialogFragment.

    class PermissionDialogFragment : DialogFragment() {
      private lateinit var activity: MainActivity

      override fun onAttach(activity: Activity) {
        if (activity is MainActivity) {
          this.activity = activity

      override fun onCreateDialog(savedInstanceState: Bundle?): Dialog {
        return AlertDialog.Builder(activity)
                 .setPositiveButton("OK") {_, _ ->
                 .setNegativeButton("NO") {_, _ ->

New maven groupId


Lastly, library’s artifacts groupId has been changed from com.github.hotchemi to org.permissionsdispatcher from 4.2.0. The reason of the change is we’ve had issues in the past that people accidentally pulled in from Jitpack, not JCenter that we provide our artifacts to. The problem behind it is Jitpack will pick up on any group ID starting with com.github. This would mean PermissionsDispatcher users need to specify jcenter() first, which contains a potential risk to encounter malicious dependencies incident. This change is merely cumbersome for existing users but we’re recognizing that preventing any security risks is the best thing to be prioritized.


It’s actually kind of incredible that we’ve been maintaining PermissionsDispatcher over 3 years and it’s used in plenty of applications across the world! I can assure we’re going to continuously push so hard to make the library better and provide pleasant developer experience to users from now on.