3.4.0 beta (supports Ask next time, Only this time, etc)

[zoontek]

Hi everyone 👋

In order to fix this irritating issue and others like "Only this time" permission grant on Android >= 12, I decided to remove SharedPreferences usage in the Android part of the module. Which mean that check() could now only respond with RESULTS.UNAVAILABLE, RESULTS.GRANTED or RESULTS.DENIED and you cannot be sure that the permission isn't RESULTS.BLOCKED until you request it. And even after that, the check method will continue to return RESULTS.DENIED.

This is far from perfect, but is related to how the Android permission works. See this comment to understand it better.

Try it!

You can try it using yarn add react-native-permissions@next and give your feedbacks ✨
For that, I also updated the example app (on this branch):

[zoontek]

This version will reintroduce this error: facebook/react-native#30158

Quite a regression, but there is currently no way to correctly detect a BLOCKED status on Android (checking shouldShowRequestPermissionRationale is a hack, and does not work when you dismiss the popup on Android >= 11).

The Android permission system is broken as its core and nobody at Google seems to care 🤷🏻‍♂️

[zoontek]

I updated the Android flow chart:

What I recommend to keep a "good" UX on Android:

1. When arriving on a screen where a permission is required, check it.
2. It could be GRANTED (use the feature immediately) or DENIED
3. If it's denied, display a screen with some explanations on why it's needed + a button to request
4. Request the permission. If it's BLOCKED, replace the content + the button with "Go to settings" instructions

It's not perfect for two reasons:

• It could be a lot better to know if the permission is BLOCKED and display "Go to settings" directly at start, but we cannot do that without relying on storage and it messes with "Only this time" grants, or "Ask next time" feature
• Dismissing the request popup will result on BLOCKED and it will switch to the "Go to settings" screen, even if the permission is still requestable.

But I'm afraid we can't achieve better.

[artyorsh]

Hi @zoontek,
Any chance we can also include #688 in the upcoming version?

[zoontek]

@artyorsh Hi! No plan for now since I still struggle a bit to get company sponsorships. If your company need it quickly, you can contact me and I will put high priority on it 🙂

[artyorsh]

@zoontek thanks for the quick response! I respect your motivation with the sponsorships - the permissions library is definitely worth it 🙂

For the Android 13 topic - most of the apps will have to upgrade to a new notification permission requirement (which doesn't necessarily involve new arch migration). Given the fact that it's available in Platform Stability, can we have a look on what other libraries do and raise the topic also in this library? I would be happy to contribute with moving the code from there to this package and checking it on emulators but I don't have a physical Android 13 device

[zoontek]

@artyorsh I will update the call for sponsors post. Indeed it's not related to the new architecture, but we need a way to make libraries development sustainable.
Currently there's a lot of feature requests on this repository, I need to found a proper way to handle that (aka, not for free - companies need to understand that it will cost them a lot more to save a few bucks 😅)

[vincent-paing]

I saw that my PR for notifee is mentioned. I'll be happy to assist with adding newly introduced permission in Android 13

[Irenedan]

This version will reintroduce this error: facebook/react-native#30158

Quite a regression, but there is currently no way to correctly detect a BLOCKED status on Android (checking shouldShowRequestPermissionRationale is a hack, and does not work when you dismiss the popup on Android >= 11).

The Android permission system is broken as its core and nobody at Google seems to care 🤷🏻‍♂️

@zoontek Hi, So how could you avoid this kind of problem in user experience?
At present, I will pop up a popup to remind the user when I receive the never_ask_again status, but this bug causes the popup to pop up when dismisses.

[zoontek]

@Irenedan You can't. Previous versions of react-native-permissions relied on SharedPreferences storage, but it introduced other issues on Android 11+

To understand the issue with the Android permission system here:

Before Android 11, a permission request couldn't be dismissed, we have to grant or denied it. On the second try, the user had a checkbox "Never ask again". As after the first try, android shouldShowRequestPermissionRationale method returns true is the user denied the request, we could be sure that it was DENIED, otherwise, it was NEVER_ASK_AGAIN. Easy.

But since Android 11, as the permission request can just be dismissed, if shouldShowRequestPermissionRationale returns false, is it because:

1. The user tick "Never ask again" / denied twice (the new system)?
2. The user dismissed the popup?

As the app briefly lose focus even if no popup appear, the only crappy hack that come to my mind would be to measure how many time it took to the user to deny. Far from perfect, but until Google fixes this we have no other choices than hacks like that. And this king of stuff couldn't be included in this library since it would not work with requestMultiple

More infos: https://developer.android.com/training/permissions/requesting

[Irenedan]

Hello, I tried to use 'yarn add react-native-permissions@next', but the app crashes when the user selects the option 'Only this time'

Phone: One plus with Android 12

[zoontek]

@Irenedan Use 3.4.0, this PR has been merged

Edit: Just tried it, no issue from the library (Google Pixel 4a, android 12):

[mikehardy]

the app crashes

This phrase should always be followed with "...and here's the stack trace from adb logcat" :-) https://developer.android.com/studio/command-line/logcat