Support asking for permissions again after returning from permissions settings

[bubenheimer]

Basic Information

Device type: Emulator
OS version: R DP1.1
EasyPermissions version: 3.0.0

Describe the problem

EasyPermissions should offer a facility to automatically request a permission again after a user has returned from manually adjusting app permissions in the app info permissions settings dialog.

In Android R DP1 a user may select "Ask every time" in the permissions settings dialog. (Corresponding to the new "Only this time" option in the regular permissions dialog.) This does not automatically grant the permission to the app, but requires another permission request from the app and affirmative response from the user before the permission is actually granted. It should be possible to recognize the user's return to the app via onActivityResult, and any needed subsequent workflow should be facilitated by EasyPermissions.

[bubenheimer]

Right now, for Android 11 DP1.1, handling the user selection in settings asks for code similar to the following, which should be possible to simplify via changed EasyPermissions APIs:

    @Override
    protected void onActivityResult(
            int requestCode,
            int resultCode,
            @Nullable Intent data
    ) {
        if (requestCode != AppSettingsDialog.DEFAULT_SETTINGS_REQ_CODE) {
            super.onActivityResult(requestCode, resultCode, data);
            return;
        }

        if (!EasyPermissions.hasPermissions(this,
                Manifest.permission.ACCESS_FINE_LOCATION)) {
            if (EasyPermissions.permissionPermanentlyDenied(this,
                    Manifest.permission.ACCESS_FINE_LOCATION)) {
                // Player chose to leave the permission denied in settings,
                // or does not understand how to change the permission in settings.
                // Offer going back to Settings, but more forcefully
                // and with additional explanation, which perhaps could also be
                // turned into a Bubble or something
                // to be available when user is in Settings
                new AppSettingsDialog.Builder(this).setRationale(
                        "This app will not work correctly without granting location access" +
                                " permission. Open the app settings screen to modify app" +
                                " permissions, then choose \"Permissions\" and \"Location\"."
                        )
                        .build()
                        .show();
            } else {
                // Player picked "ask every time" in settings,
                // so ask for permissions again the regular way,
                // but without the rationale dialog,
                // because that's clutter at this point
                requestPermissions(new String[] { Manifest.permission.ACCESS_FINE_LOCATION },
                        PERMISSIONS_REQUEST_ACCESS_LOCATION);
            }
        }
    }

[bubenheimer]

I have created a related Android platform issuetracker issue regarding the incorrect behavior of shouldShowRequestPermissionRationale():
https://issuetracker.google.com/issues/151427074

[samtstern]

@bubenheimer thanks for filing this. So is the main request here to add some request permissions function that never shows rationale? That way you don't need to do the platform requestPermissions call?

[bubenheimer]

I'm not sure what the best APIs might be to add to capture the new settings-related workflows in Android 11. I'd assume that related Android 11 APIs are still in flux, so this issue is more of a TODO reminder at this point to call out a future need for change. Here are my thoughts:

In the foreground location permission case that I am focusing on in this issue there are 3 possible outcomes when returning from settings. That could be captured by 3 separate methods similar to how EasyPermissions offers 2 methods to capture the results from requestPermissions().

When taking the new Android 11 behaviors for background location permissions into account the situation would seem to become more complex. I don't use background location, so I don't have good ideas or sample code to capture what's needed: https://developer.android.com/preview/privacy/location

I'm not sure what the behavior of shouldShowRequestPermissionRationale() will be in the Android 11 release, if the Android platform issuetracker bug is addressed. There may or may not be a need for a request permission function without rationale.

[bubenheimer]

For reference, here's the URL for other Android 11 permission changes, in addition to background location permission changes: https://developer.android.com/preview/privacy/permissions

[artakka]

This is pretty annoying. Is there going to be some sort of solution?