Permissionsdispatcher: Mechanism that delegate the check work to users

[hotchemi]

ref: https://github.com/hotchemi/PermissionsDispatcher/issues/187

This is definitely unexpected, but some devices like from Xiaomi need different check flow to get the state of permission.
Currently we provide PermisisonUtils in library module, but I'm thinking to provide the following interface to allow users to put in their original logic.

@RuntimePermission(checker = XiaomiChecker.class) // default value is PermisisonUtils.class
class Some {
}

@aurae @shiraji What do you think?

@a1018875550 Can you solve the problem with above interface?

[MichaelJokAr]

It's a good idea,but it will change the processor code;I will try to achieve it for Java

[hotchemi]

Umm? in that case all you have to do is to create your own checher in Java and just inject it.

[MichaelJokAr]

just need I to push the XiaomiChecker.class?

[hotchemi]

If we will impl that yes, user's task is to create checker class on app side and just inject it.

[mannodermaus]

I'm not against the idea of generalizing the "PermissionChecker" implementation per se, however I'm curious as to what the generalized interface would look like? @a1018875550, can you explain in greater detail the differences of Xiaomi's implementation for runtime permissions, compared to stock Android? Specifically, how do rationales and the "never ask again" mechanism work?

I'm picturing an extension library that provides Xiaomi compatibility, which may be added as an additional dependency on top of PermissionsDispatcher. When done right, this should not interfere with the existing processor code in place for Java, however my confusion regarding how Xiaomi deals with this remains.

[shiraji]

@aurae are you saying we are going to generate PermissionUtils class at compile time? How to accomplish extension mechanism? It still depends on what @a1018875550 answer but I'm interested to your idea.

[hotchemi]

I guess the only difference is here. We have to use AppOpsManager to get the state of permission correctly, right? @a1018875550

https://github.com/a1018875550/PermissionDispatcher/blob/master/library/src/main/android/org.jokar.permissiondispatcher.library/PermissionUtils.java#L128

[hotchemi]

And one more reason I proposed the feature that delegates the check to user is we can deal with similar problem like particular device from awesome hardware manufacturer would have a different permission mechanism...
I hope it won't occur but this is Android platform, it's probable...so in that case we don't want to distribute each special library right? The simplest solution is delegation itself.

[mannodermaus]

@shiraji I was piggy-backing off Katafuchi-san's original idea, which is to allow users to provide the "checker implementation" within the @RuntimePermissions annotation. We'd have to generalize an interface that PermissionsDispatcher's processor uses to perform the checks, for instance:

public interface Checker {
    // Just an example
    boolean checkPermission(Context context, String[] permission);
}

Then, within our permissionsdispatcher artifact, we would include the default implementation which is used for most cases:

public final class DefaultChecker implements Checker {
    @Override public boolean checkPermission(Context context, String[] permission) {
        // For example, using support.v4.PermissionChecker...
    }
}

Finally, all of the Xiaomi stuff (which may even depend on some more libraries, I don't really know much about the system) would go in a separate artifact that references the main one, e.g. permissionsdispatcher-xiaomi. That would have a separate implementation:

public final class XiaomiChecker implements Checker {
    @Override public boolean checkPermission(Context context, String[] permission) {
        // Using whatever Xiaomi would need differently...
    }
}

Developers targetting that platform could then add the permissionsdispatcher-xiaomi artifact as an additional compile dependency and use the XiaomiChecker.class in their annotations.

The processor chooses and instantiates Checker instances on a per-class basis, based on the user's choice. Therefore, the implementation details are hidden to the processor itself.

[shiraji]

Oh i see. I was thinking a plugin feature that AutoValue or AndroidAnnotation provide. Let other developers extends it. Like "AndroidAnnotationsPermissionsDispatcherPlugin". I didn't like adding both DefaultChecker(ProcessorUtils) and XiaomiChecker to Xiaomi device. Maybe there is no such way or requires breaking changes... At this moment, I could not come up better solution other than @hotchemi and @aurae suggest. (experimented "adapter" -> ❌ )

BTW, do you guys want to add permissionsdispatcher-xiaomi project in this repo? I am too scared to have the project since none of contributors own the device. Is there English documentation for Xiaomi's runtime permission?

[MichaelJokAr]

I know your worried!The xiaomi phon has one hundred million users in China.So I must do special judge for it as A Chinese Android Developer.And I think @hotchemi make a very good idea.Because not only has one phone change the permission rule in the world!If we use this idea,when other developers want to add they check ,we don't need to change the plug code .The plug became very useful 😋

I'm sorry to there has no any English document for "xiaomi" runtime permission.

[MichaelJokAr]

@hotchemi yes it only add AppOpsManager juggle in "xiaomi" phone

[hotchemi]

@aurae @shiraji Thx for giving your thoughts and digging into more detail! My idea is definitely what @aurae explained above.

@a1018875550 Thx for your check. So I'm gonna investigate and probably implement this mechanism by next release.

[MichaelJokAr]

It's very busy for those days;And do I need to pull the interface code?

[hotchemi]

@a1018875550 Sorry I've been busy as well so let me implement this weekend.

[MichaelJokAr]

thanks!

[CosminMihuMDC]

Any update? thanks :D

[hotchemi]

Ah sorry forgot to do that...

[n0m0r3pa1n]

I have another question guys. Can the @RuntimePermissions annotation be used in classes, not only fragments and activities? For example, I have a class called FileChooser, which sends an intent to the system to pick a file. After that, it parses the response and gets the file. The idea is that I have the context in the FileChooser class and I want to have the permissions inside of it. Is there any way the library can generate the code for the FileChooser class? Or the only way is to use the PermissionUtils directly?

[shiraji]

@n0m0r3pa1n That's not related to this issue. Could you find the related issue? If I remember correctly, there were some issues asking using Non-Activity/Fragment.

[hotchemi]

@n0m0r3pa1n Here https://github.com/hotchemi/PermissionsDispatcher/issues/182#issuecomment-238138534

[MichaelJokAr]

It's too long time for this plan.And it still need I write the base PermisisonUtils interface?

[hotchemi]

@a1018875550 Sorry for the late, I'm working at https://github.com/hotchemi/PermissionsDispatcher/pull/228(actually it turned out we need some sorting out of dependency graph).

[hotchemi]

Well...I just realised my idea works when the app is only for Xiaomi but if developer targets both Android and Xiaomi it will mess up...
@a1018875550 You are targeting both Android and Xiaomi with one app right?

[hotchemi]

The only possible solution that in my mind is distinguish Xiaomi like the following...

https://github.com/leolin310148/ShortcutBadger/blob/master/ShortcutBadger/src/main/java/me/leolin/shortcutbadger/ShortcutBadger.java#L147

[MichaelJokAr]

yes ,I'm not only design app for "Xiaomi";
But I think your idea it's right; Just like the link, we can make distinguish int the checker,when we need to target "Xiaomi" or other phone;

[hotchemi]

ic. In that sense the countermeasure will be quite simple. Let me continue the work.

[hotchemi]

@a1018875550 Finally Xiaomi support was shipped as 2.3.0! Sorry that it's been a long time.
https://github.com/hotchemi/PermissionsDispatcher/releases/tag/2.3.0

[MichaelJokAr]

thx,but I think add a checker is a good way to most android device!If you have this plan😀😀

[hotchemi]

Well we don't have a plan to do that because I encountered the problem as I described https://github.com/hotchemi/PermissionsDispatcher/issues/211#issuecomment-265660588 and it seems the only exception is Xiaomi right now.

[rpattabi]

@hotchemi Please clarify this: Is the issue with Xiaomi phones only when checking for the permissions or for requesting permissions also?

I am asking this since stackoverflow has an answer about Xiaomi permissions issue where the solution is to ask all the permission in a group instead of just a specific permission!

[shiraji]

It's for checking the permissions.

As far as I understand, the way PermissionsDispatcher handles Xiaomi is better than asking all the permissions in a group. What is your actual problem? @rpattabi

[rpattabi]

@shiraji I am not aware if the issue reported at stackoverflow is still an issue or not, neither do I have access to Xiaomi phone. I just learned about the permission problem with Xiaomi through this thread. When I saw the other issue reported at Stackoverflow, I wanted to keep you guys informed. It is clear now that this library is addressing checking the permissions. Thanks.