Behavior changes: all apps

The Android 11 platform includes behavior changes that may affect your app. The following behavior changes apply to all apps when they run on Android 11, regardless of targetSdkVersion. You should test your app and then modify it as needed to support these properly, where applicable.

Make sure to also review the list of behavior changes that only affect apps targeting Android 11.

JobScheduler API call limits debugging

Android 11 offers debugging support for apps to identify potential JobScheduler API invocations that have exceeded certain rate limits. Developers can use this facility to identify potential performance issues. For apps with the debuggable manifest attribute set to true, JobScheduler API invocations beyond the rate limits will return RESULT_FAILURE. Limits are set such that legitimate use cases should not be affected.

One-time permissions

In Android 11, whenever your app requests a permission related to location, microphone, or camera, your app is granted a temporary one-time permission. To learn more about this change, see the one-time permissions section on the page that discusses privacy changes related to permissions in Android 11.

User choice can restrict when a permission dialog appears

Android 11 discourages repeated requests for a specific permission. If the user taps Deny twice for a specific permission during your app's lifetime of installation on a device, this action implies "don't ask again". To learn more about this change, see the permission dialog visibility section on the page that discusses privacy changes related to permissions in Android 11.

Background location access

If your app targets Android 11, you cannot directly request all-the-time access to background location. Even if your app targets Android 10 (API level 29) or lower, users see a system dialog that includes buttons to control foreground location access.

To learn more about this change, see the background location access section on the page that discusses privacy changes related to location in Android 11.

Storage UI

Android 11 introduces several user-facing changes related to storage permissions, including the name of the Storage runtime permission and the contents of the dialog that explains your app's request for a storage permission. To learn more about these changes, see the permissions section on the page that discusses privacy changes related to storage in Android 11.

Change to ACTION_MANAGE_OVERLAY_PERMISSION intent behavior

Beginning with Android 11, ACTION_MANAGE_OVERLAY_PERMISSION intents always bring the user to the top-level Settings screen where they 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.

All Files Access

Some apps have a core use case that requires broad file access, such as file management or backup & restore operations. They can get All Files Access by declaring the special MANAGE_EXTERNAL_STORAGE permission.

To learn more about this permission, see the All Files Access section on the page that discusses privacy changes related to storage in Android 11.

Non-SDK interface restrictions

Android 11 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 11, some of these changes might not immediately affect you. However, while you can currently use non-SDK interfaces that are part of the greylist (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 11. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.

File descriptor sanitizer (fdsan)

Android 10 introduced fdsan (file descriptor sanitizer). fdsan detects mishandling of file descriptor ownership, such as use-after-close and double-close. The default mode for fdsan is changing in Android 11. fdsan now aborts upon detecting an error; the previous behavior was to log a warning and continue. If you're seeing crashes due to fdsan in your application, refer to the fdsan documentation.