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.

## One-time permissions

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](https://developer.android.com/training/permissions/requesting#one-time).
| **Note:** If your app already follows best practices when it[requests runtime permissions](https://developer.android.com/training/permissions/requesting), you don't need to change your app to support 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](https://developer.android.com/training/permissions/requesting), 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.
| **Note:** The system resets only[runtime permissions](https://developer.android.com/guide/topics/permissions/overview#runtime_requests_android_60_and_higher), which are the permissions that display a runtime prompt to the user when requested.

Learn more about how the system[auto-resets permissions of unused apps](https://developer.android.com/training/permissions/requesting#auto-reset-permissions-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<var translate="no">PACKAGE_NAME</var>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`USER_SET`. Permissions that have been denied permanently by selecting**Deny** twice are flagged by`USER_FIXED`.

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:

<br />

```
adb shell pm clear-permission-flags PACKAGE_NAME PERMISSION_NAME user-set user-fixed
```

<br />

<var translate="no">PERMISSION_NAME</var>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](https://developer.android.com/reference/android/Manifest.permission#constants_1).
| **Note:** If your app already follows[best practices related to permissions](https://developer.android.com/privacy/best-practices#permissions), you don't need to change your app to support this behavior change.

Learn more about how to[handle permission denial](https://developer.android.com/training/permissions/requesting#handle-denial)in your app.

## System alert window changes

Android 11 makes several changes to how apps are granted the[`SYSTEM_ALERT_WINDOW`](https://developer.android.com/reference/android/Manifest.permission#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`](https://developer.android.com/reference/android/app/role/RoleManager#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`](https://developer.android.com/reference/android/media/projection/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`](https://developer.android.com/reference/android/provider/Settings#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`](https://developer.android.com/reference/android/provider/Settings#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`](https://developer.android.com/reference/android/Manifest.permission#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 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.

## Phone numbers

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[`READ_PHONE_NUMBERS`](https://developer.android.com/reference/kotlin/android/Manifest.permission#read_phone_numbers)permission, instead of the`READ_PHONE_STATE`permission.

- The`getLine1Number()`method in both the[`TelephonyManager`](https://developer.android.com/reference/kotlin/android/telephony/TelephonyManager#getline1number)class and the[`TelecomManager`](https://developer.android.com/reference/kotlin/android/telecom/TelecomManager#getline1number)class.
- The unsupported`getMsisdn()`method in the[`TelephonyManager`](https://developer.android.com/reference/kotlin/android/telephony/TelephonyManager)class.

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:  

```xml
<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>
```

## Additional resources

For more information about the changes to permissions in Android 11, view the following materials:

### Videos

[Developing with the latest privacy changes in Android 11](https://www.youtube.com/watch?v=MXlVj-EYgIQ)