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 or higher, 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.
Starting 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.
Learn more about how the system handles one-time permissions.
Auto-reset permissions from unused apps
If your app targets Android 11 or higher 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.
Learn more about how the system auto-resets permissions of unused apps.
Permission dialog visibility
Starting in Android 11, if the user taps Deny for a specific permission more than once during your app's lifetime of installation on a device, the user doesn't see the system permissions dialog if your app requests that permission again. The user's action implies "don't ask again." On previous versions, users would see the system permissions dialog each time your app requested a permission, unless the user had previously selected a "don't ask again" checkbox or option. This behavior change in Android 11 discourages repeated requests for permissions that users have chosen to deny.
To identify whether an app has been permanently denied permissions (for debugging and testing purposes), use the following command:
adb shell dumpsys package PACKAGE_NAME
Where PACKAGE_NAME is the name of the package to inspect.
The output of the command contains sections that look like this:
... runtime permissions: android.permission.POST_NOTIFICATIONS: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED] android.permission.ACCESS_FINE_LOCATION: granted=false, flags=[ USER_SET|USER_FIXED|USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED] android.permission.BLUETOOTH_CONNECT: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED] ...
Permissions that have been denied once by the user are flagged by
Permissions that have been denied permanently by selecting Deny twice are
During testing you might want to reset these flags to ensure that testers aren't surprised when the request dialog isn't shown. To do this, use the command:
adb shell pm clear-permission-flags PACKAGE_NAME PERMISSION_NAME user-set user-fixed
PERMISSION_NAME is the name of the permission you want to reset. To view a complete list of Android app permissions, visit the permissions API reference page.
Learn more about how to handle permission denial in your app.
System alert window changes
Android 11 makes 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 isn't supported as of
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 or higher 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="android.permission.READ_PHONE_STATE" android:maxSdkVersion="29" /> <uses-permission android:name="android.permission.READ_PHONE_NUMBERS" /> </manifest>
For more information about the changes to permissions in Android 11, view the following materials: