What is new in Android 11 Preview | Getting started with | Android 11 Developer Preview | Android Developers | Behavior changes

Published by inkskull on

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.

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.

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.

App usage stats privacy

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.

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 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.

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.

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.

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.

SSL sockets use Conscrypt SSL engine by default

In Android 11, the default SSLSocket implementation uses the Conscrypt SSLEngine.

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.

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.

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.

SSL sockets use Conscrypt SSL engine by default

In Android 11, the default SSLSocket implementation uses the Conscrypt SSLEngine.

Categories: Android

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Social Media Auto Publish Powered By : XYZScripts.com