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.


Android 11 introduces a large number of changes and restrictions to enhance user privacy. To learn more, see the Privacy page.


Perform file-based encryption after an OTA restart without user credentials

After the device receives an OTA update and restarts, the Credential Encrypted keys that are placed in credential-protected storage are immediately available for File-Based Encryption (FBE) operations. Therefore, your app can perform actions related to file-based encryption before the user enters their PIN, pattern, or password to unlock the device following the restart.

SSL sockets use Conscrypt SSL engine by default

Android's default SSLSocket implementation is based on Conscrypt. Since Android 11, that implementation is internally built on top of Conscrypt's SSLEngine.

Scudo Hardened Allocator

Android 11 uses the Scudo Hardened Allocator internally to service heap allocations. Scudo is capable of detecting and mitigating some types of memory safety violations. If you are seeing Scudo-related crashes (for example, Scudo ERROR:) in native crash reports, refer to the Scudo troubleshooting documentation.

App usage stats

To better protect users, Android 11 stores each user's app usage stats in credential encrypted storage. Therefore, neither the system nor any apps can access that data unless isUserUnlocked() returns true, which occurs after one of the following takes place:

  • The user unlocks their device for the first time after a system startup.
  • The user switches to their account on the device.

If your app already binds to an instance of UsageStatsManager, check that you call methods on this object after the user unlocks their device. Otherwise, the API now returns null or empty values.


Support for concurrent use of more than one camera

Android 11 adds APIs to query support for using more than one camera at a time, including both a front-facing and rear-facing camera.

To check for support on the device on which your app is running, use the following methods:


Open Mobile API changes

Beginning with Android 11, Open Mobile API (OMAPI) has additional functionality:

  • Parse rules for carrier privileges.

  • Customize embedded Secure Element (eSE) access or provision an eSE using one or more of the following:

    • System privileged permission
    • Configurable Access Rule Application Master (ARA-M) application identifiers (AIDs)
    • System API to reset OMAPI reader
  • Provide readers a clear indicator for applications to filter device capability.

Performance and debugging

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.

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.


Screen readers require definitions of click-based accessibility actions

In previous versions of Android, the framework dispatched touch events to widgets that didn't handle click-based accessibility actions properly. Typically, these views handle touch events directly instead of registering a click listener.

To create more consistent behavior in apps that correctly define accessibility actions, Android 11 never dispatches touch events. Instead, the system relies entirely on the click-based accessibility actions: ACTION_CLICK and ACTION_LONG_CLICK. This change affects the behavior of screen readers.

The system handles widgets that use the OnClickListener and OnLongClickListener interfaces. If your app uses a more customized widget that relies on the OnTouchListener interface, however, you need to define custom handlers for the click-based accessibility actions. To do so, call the replaceAccessibilityAction() method for each action, as shown in the following code snippet:


// Assumes that the widget is designed to select text when tapped and select
// all text when long-tapped. In its strings.xml file, this app has set
// "select" to "Select" and "select_all" to "Select all", respectively.
) { view, commandArguments ->

) { view, commandArguments ->


// Assumes that the widget is designed to select text when tapped and select
// all text when long-tapped. In its strings.xml file, this app has set
// "select" to "Select" and "select_all" to "Select all", respectively.
ViewCompat.replaceAccessibilityAction(WIDGET, ACTION_CLICK,
        (view, commandArguments) -> {

ViewCompat.replaceAccessibilityAction(WIDGET, ACTION_LONG_CLICK,
        (view, commandArguments) -> {

Declare accessibility button usage in metadata file

Starting in Android 11, your accessibility service cannot declare an association with the system's accessibility button at runtime. If you append AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON to the flags property of an AccessibilityServiceInfo object, the framework doesn't pass accessibility button callback events to your service.

Instead, declare your accessibility service's association with the accessibility button using the flagRequestAccessibilityButton flag in your accessibility service metadata file, typically res/raw/accessibilityservice.xml.

User interface


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 app are automatically granted the SYSTEM_ALERT_WINDOW permission upon request. 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.

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.

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.

App compatibility

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.

Maps v1 shared library removed

V1 of the Maps shared library has been completely removed in Android 11. This library was previously deprecated and stopped functioning for apps in Android 10. Apps that previously relied on this shared library for devices running Android 9 (API level 28) or lower should use the Maps SDK for Android instead.