Android 11 is scheduled to be released this year in September, but we will get the first Android 11 beta version on June 3, 2020. The new Android version contains some new features and important developer focused updates, as seen in the developer previews. Android 11 features include airdrop-style file sharing, motion sense gesture, screen recording and many more. The behavior changes in the latest Android version may affect your app regardless of the target SDK version. So let’s get familiar with the behavior changes that will help you make your app compatible with Android version 11.


In the new Android, your accessibility service cannot declare an association with the system’s accessibility button at runtime. You can 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. Earlier we used to add AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON to the flags property of an AccessibilityServiceInfo object. But now the framework won’t pass accessibility button callback events to your service.

Open Mobile API changes

In Android 11, Open Mobile API has additional functionality:

1. Parse rules for carrier privileges.
2. 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

3. Provide readers a clear indicator for applications to filter device capability.


The new Android 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 if the user unlocks their device for the first time after a system startup or 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 will return null or empty values.

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. Refer to the Scudo troubleshooting Android documentation if you see any Scudo-related crashes (for example, Scudo ERROR:) in native crash reports. Also, Android’s default SSLSocket implementation is internally built on top of Conscrypt SSLEngine.

App Compatibility

Android 11 update includes 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, refer to Updates to non-SDK interface restrictions in Android 11.


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.

The default mode for fdsan is changing in Android 11. It detects mishandling of file descriptor ownership, such as double-close and use-after-close. Previously fdsan used to log a warning and continue but now it aborts upon detecting an error. If you’re seeing crashes due to fdsan in your application, refer to the fdsan documentation.

Privacy Changes

There are some crucial changes in the privacy control in Android 11 and developers should review the privacy features and test their apps for compatibility. The first change we will talk about is One-time permissions. Now users can grant temporary access to location, microphone, and camera through a one-time permission. This feature grants more control to the users who do not wish to share information while using any app that uses these features. The next change is in package visibility. Android 11 changes how apps query and interact with other installed apps on the same device. Add the element to your app’s manifest and this change will affect the apps that target Android 11. There is an update for the background location access which will affect the apps that need all time access to location. Request foreground (coarse or fine) and background location permissions incrementally in separate calls to the permission request method. Before each request, use a full screen view to explain the benefits that users receive for granting that permission.

Apart from this there are many UI changes like system_alert_window permission and manage_overlay permission. For more information you can visit the Android documentation and also check out the behaviour changes in apps targeting Android 11.