Android 11 Auto Revoke Feature Request

[Mattimus333]

Feature request

Android 11 has a new feature that allows the user to enable a switch that will "auto revoke permissions" after a few months of no use. I believe there are ways to detect this and prompt the user to change it.

Why it is needed

Make full use of Android 11 features. Definitely not necessary but would be nice considering this library is "react-native-permissions"

Possible implementation

https://developer.android.com/reference/android/content/Intent#ACTION_AUTO_REVOKE_PERMISSIONS

https://developer.android.com/reference/android/content/pm/PackageManager#isAutoRevokeWhitelisted(java.lang.String)

Code sample

Upvote & Fund

• This repository is using Polar.sh so you can help prioritize & fund this issue.
• The funding will only be unlocked once this issue is completed.

[mikehardy]

I think this is the most accurate API for the second link, as the first link requires permissions to call but this one may be called by the package for it's own status

https://developer.android.com/reference/android/content/pm/PackageManager#isAutoRevokeWhitelisted()

What's the possible implementation though? This isn't really a permission, it's just a status of the app, so it would be an API available to any caller I think from the base module, and then similar to openSettings API already existing you could code up an API that created an Intent using the information from your first link and called it with a response handler perhaps?

[zoontek]

Hi @Mattimus333,
What would be the purpose of the feature? Check if the user put the app in a whitelist and nag him if it hasn't done it yet?

[Mattimus333]

Nag is a strong word. It could definitely help remind the user that the app my not work as expected if they have this setting turned on.

[mikehardy]

I responded quickly last time and am doing so again because this would be interesting for my app actually, and for exactly the reason you state. In general my app exposes these sorts of privacy tradeoffs to the user with tangible benefits (typically once - echoing @Mattimus333 with regard to "nag" or simply "mention") so it would be nice to have. It wouldn't be high on my priority list to code up vs my current priorities but I could be a good testing counterparty if it was acceptable and you wanted to give it a shot @Mattimus333

[zoontek]

Nag is a strong word. It could definitely help remind the user that the app my not work as expected if they have this setting turned on.

Sorry, english is not my first language. I didn't know it was that strong.

As I read, the permissions are revoked after a few months without usage: https://developer.android.com/about/versions/11/privacy/permissions#auto-reset. As this library encourage the developer to request permissions at runtime and only when you need it, it shouldn't create any issue.

I understand it might be valuable in some extremely rare cases, but a few months is a lot. I'm not sure it has to be a high priority feature to develop.

[Mattimus333]

Sooner or later I'm going to have to implement this feature myself for a project I'm working on so if you were interested I could include it in this library and hit you with a pull request, but if you don't think it fits in the scope of this library that is understandable. @zoontek Let me know what you think.

@mikehardy Exactly what I'm thinking. If the user wants to enable this new setting, fine, but it is good to warn them what the effects might be! If I do give it a shot I'll let you know. A second set of eyes is always appreciated on the testing front.

[mikehardy]

This is one that I think is almost react-native-device-info (I maintain that one right now) but since it is permission-related it seems like a better home here.

One of the things that I do with RNDI @zoontek is just expose whatever API seems like a fit with the package that the device supports - a philosophy of "if there is a native API, I will expose it".

Similar to the GPS case you never know what the app is doing and maybe it's the next cure for cancer or COVID contract tracing or something, what do I know :-) ? If the platforms themselves were going in the non-privacy direction I would feel more compelled to personally advocate but (feels weird to type this...) even Android right now is getting to be fairly protective by default and require an appropriate amount of user transparency (a great thing)

As for the English as a second language thing, your English is of course great (of which you are likely aware) but I am always tuning my second language, so just for that purpose yes - "nag" is always a negative thing, like you have been asked the 5th time for something even though you answered the same each time. Of course many apps do nag, but ideally we here only code very respectful apps ;-). Cheers

[boazpoolman]

I'm looking to implement this feature for one of our projects.
Ideally I'd implement it directly in this package, rather than in our own project. For reusability purposes.

@zoontek Do you have any requirements / specifications on how you would like to see this implemented?
I figured we could just expose the getUnusedAppRestrictionsStatus as a ReactMethod. I believe that's about all we can do, as disabling this setting through code is not possible (and rightfully so).

[zoontek]

@boazpoolman This API looks like a shitshow, so if you can abstract this to a boolean (and not "ERROR" | "FEATURE_NOT_AVAILABLE" | "DISABLED" | "API_30_BACKPORT" | "API_30" | "API_31" 😅), it could be nice.

[boazpoolman]

Yep. That was what I was thinking as well.