Permissions updates in Android 11

Android 11 gives users the ability to specify more granular permissions for location, microphone, and camera. Additionally, the system resets the permissions of unused apps that target Android 11, and apps might need to update the permissions that they declare if they use the system alert window or read information related to phone numbers.

We're interested in hearing your feedback! Please take this short survey to let us know how you're using the feature. In particular, tell us about use cases impacted by this feature.

One-time permissions

In Android 11, whenever your app requests a permission related to location, microphone, or camera, the user-facing permissions dialog contains an option called Only this time. If the user selects this option in the dialog, your app is granted a temporary one-time permission.

Your app can then access the related data for a period of time that depends on your app's behavior and the user's actions:

  • While your app's activity is visible, your app can access the data.
  • If the user brings your app to the background, your app can continue to access the data for a short period of time.
  • If you launch a foreground service while the activity is visible, and the user then moves your app to the background, your app can continue to access the data until that foreground service stops.
  • If the user revokes the one-time permission, such as in system settings, your app cannot access the data, regardless of whether you launched a foreground service. As with any permission, if the user revokes your app's one-time permission, your app's process terminates.

When the user next opens your app and a feature in your app requests access to location, microphone, or camera, the user is prompted for the permission again.

Auto-reset permissions from unused apps

If your app targets Android 11 and isn't used for a few months, the system protects user data by automatically resetting the sensitive runtime permissions that the user had granted your app. This action has the same effect as if the user viewed a permission in system settings and changed your app's access level to Deny. If your app follows best practices for requesting permissions at runtime, you shouldn't need to make any changes to your app. That's because, as the user interacts with features in your app, you should verify that the features have the permissions that they need.

Request user to disable auto-reset

If needed, you can ask the user to prevent the system from resetting your app's permissions. This is useful in situations where users expect your app to work primarily in the background, even without the user interacting with your app, such as in the following use cases:

Figure 1. User has disabled the auto-resetting of permissions for a given app.
  • Provide family safety
  • Sync data
  • Communicate with smart devices
  • Pair to companion devices

To direct the user to your app's page in system settings, invoke an intent that includes the Intent.ACTION_AUTO_REVOKE_PERMISSIONS intent action. From this screen, users can prevent the system from resetting your app's permissions by doing the following:

  1. Tap Permissions, which loads the App permissions settings screen.
  2. Turn off the option called Remove permissions if app isn't used, as shown in Figure 1.

Determine whether auto-reset is disabled

To check whether auto-reset functionality is disabled for your app, call isAutoRevokeWhitelisted(). If this method returns true, then the system doesn't auto-reset your app's permissions.

Test the auto-reset feature

To verify that the system resets your app's permissions, do the following:

  1. Save the default amount of time that the system waits to reset an app's permissions. That way, you can restore it after testing:

    threshold=$(adb shell device_config get permissions \
  2. Reduce the amount of time that the system waits to reset the permissions. In the following example, the system is modified such that it resets an app's permissions only one second after you stop interacting with an app:

    adb shell device_config put permissions \
      auto_revoke_unused_threshold_millis2 1000
  3. Invoke the auto-reset process manually, as shown in the following snippet. Make sure that the test device has been turned on for a short while, about 45 seconds, before you run this command.

    adb shell cmd jobscheduler run -u 0 -f \ 2
  4. Verify that your app can handle the auto-reset event.

  5. Restore the default amount of time that the system waits before it auto-resets an app's permissions:

    adb shell device_config put permissions \
      auto_revoke_unused_threshold_millis2 $threshold

Permission dialog visibility

Android 11 discourages requests for permissions that users have chosen to deny. If the user repeatedly taps Deny for a specific permission during your app's lifetime of installation on a device, this action implies "don't ask again."

If your app already follows best practices related to permissions, you don't need to change your app to support this behavior change.

System alert window changes

There are several changes to how apps are granted the SYSTEM_ALERT_WINDOW permission. The changes are intended to protect users by making the permission grant more intentional.

Certain apps are automatically granted SYSTEM_ALERT_WINDOW permission upon request

Certain classes of apps are automatically granted the SYSTEM_ALERT_WINDOW permission upon request:

  • Any app that has ROLE_CALL_SCREENING and requests SYSTEM_ALERT_WINDOW is automatically granted the permission. If the app loses ROLE_CALL_SCREENING, it loses the permission.

  • Any app that is capturing the screen via a MediaProjection and requests SYSTEM_ALERT_WINDOW is automatically granted the permission unless the user has explicitly denied the permission to the app. When the app stops capturing the screen, it loses the permission. This use case is primarily intended for game livestreaming apps.

These apps do not need to send ACTION_MANAGE_OVERLAY_PERMISSION to get the SYSTEM_ALERT_WINDOW permission; the apps can simply request SYSTEM_ALERT_WINDOW directly.

MANAGE_OVERLAY_PERMISSION intents always bring user to system permissions screen

Beginning with Android 11, ACTION_MANAGE_OVERLAY_PERMISSION intents always bring the user to the top-level Settings screen, where the user can grant or revoke the SYSTEM_ALERT_WINDOW permissions for apps. Any package: data in the intent is ignored.

In earlier versions of Android, the ACTION_MANAGE_OVERLAY_PERMISSION intent could specify a package, which would bring the user to an app-specific screen for managing the permission. This functionality is no longer supported in Android 11. Instead, the user must first select the app they wish to grant or revoke the permission to. This change is intended to protect users by making the permission grant more intentional.

Phone numbers

Android 11 changes the phone-related permission that your app uses when reading phone numbers.

If your app targets Android 11 and needs to access the phone number APIs shown in the following list, you must request the READ_PHONE_NUMBERS permission, instead of the READ_PHONE_STATE permission.

If your app declares READ_PHONE_STATE to call methods other than the ones in the previous list, you can continue to request READ_PHONE_STATE across all Android versions. If you use the READ_PHONE_STATE permission only for the methods in the previous list, however, update your manifest file as follows:

  1. Change your declaration of READ_PHONE_STATE so that your app uses the permission only on Android 10 (API level 29) and lower.
  2. Add the READ_PHONE_NUMBERS permission.

The following manifest declaration snippet demonstrates this process:

    <!-- Grants the READ_PHONE_STATE permission only on devices that run
         Android 10 (API level 29) and lower. -->
    <uses-permission android:name="READ_PHONE_STATE"
                     android:maxSdkVersion="29" />
    <uses-permission android:name="READ_PHONE_NUMBERS" />