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.
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:
- 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
intent action. From this screen, users can prevent the system from resetting
your app's permissions by doing the following:
- Tap Permissions, which loads the App permissions settings screen.
- 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
If this method returns
true, then the system doesn't auto-reset your app's
Test the auto-reset feature
To verify that the system resets your app's permissions, do the following:
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 \ auto_revoke_unused_threshold_millis2)
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
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 \ com.google.android.permissioncontroller 2
Verify that your app can handle the auto-reset event.
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
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
permission upon request:
Any app that has
SYSTEM_ALERT_WINDOWis automatically granted the permission. If the app loses
ROLE_CALL_SCREENING, it loses the permission.
Any app that is capturing the screen via a
SYSTEM_ALERT_WINDOWis 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
to get the
SYSTEM_ALERT_WINDOW permission; the apps can simply request
MANAGE_OVERLAY_PERMISSION intents always bring user to system permissions screen
Beginning with Android 11,
intents always bring the user to the top-level Settings screen, where the
user can grant or revoke the
permissions for apps. Any
package: data in the intent is ignored.
In earlier versions of Android, the
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.
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
permission, instead of the
getLine1Number()method in both the
TelephonyManagerclass and the
- The unsupported
getMsisdn()method in the
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:
- Change your declaration of
READ_PHONE_STATEso that your app uses the permission only on Android 10 (API level 29) and lower.
- Add the
The following manifest declaration snippet demonstrates this process:
<manifest> <!-- 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" /> </manifest>