Features and APIs Overview

Android 11 introduces great new features and APIs for users and developers. This document highlights what's new for developers.

To learn about the new APIs, read the API diff report, or visit the Android API reference—new APIs are highlighted for visibility. Also, to learn about areas where platform changes may affect your apps, be sure to check out Android 11 behavior changes for apps that target Android R and for all apps), as well as privacy changes.

Data access auditing

We're interested in hearing your feedback! Please take this short survey to let us know how you're using the feature. In particular, tell us about use cases impacted by this feature.

To provide more transparency into how your app and its dependencies access private data from users, Android 11 introduces data access auditing. By using this feature, you can better identify and rectify potentially unexpected data access.

To learn more about this feature, read the data access auditing section on the page that discusses privacy changes related to permissions.

Performant graphics debug layer injection

Applications can now load external graphics layers (GLES, Vulkan) into native application code to expose the same functionality as a debuggable app, but without incurring the performance overhead. This feature is especially important when profiling your application with tools like GAPID. To profile your app, include the following meta-data element in your app manifest file instead of making the application debuggable:

<application ... >
    <meta-data android:name="com.android.graphics.injectLayers.enable"
                  android:value="true" />
</application>

Batch operations for media files

For consistency across devices and added user convenience, Android 11 adds several methods to the MediaStore API. To learn more about these methods, see the perform batch operations section on the Android 11 privacy page related to storage.

Rich media in quick replies

Beginning in Android 11, users can insert images and other rich media content into quick replies. To support this feature, apps need to add information to RemoteInput notifications specifying which MIME types they can handle. Do this by calling RemoteInput.Builder.setAllowDataType(). The app must also check any RemoteInput broadcasts that it receives to see if the broadcast contains content in any of those types; use RemoteInput.getDataResultsFromIntent() to do this.

Access to media files using raw file paths

Starting in Android 11, apps that have the READ_EXTERNAL_STORAGE permission can read a device's media files using direct file paths and native libraries. To learn more about this capability, see the access files using raw paths section on the Android 11 privacy page related to storage.

Secure sharing of large datasets

In some situations, such as those that involve machine learning or media playback, your app might want to use the same large dataset as another app. In previous versions of Android, your app and another app would each need to download a separate copy of the same dataset.

To help reduce data redundancy, both over the network and on disk, Android 11 allows these large datasets to be cached on the device using shared data blobs. To learn more about sharing datasets, see the in-depth guide on sharing large datasets.

App process exit reasons

We're interested in hearing your feedback! Please take this short survey to let us know how you're using the feature. In particular, tell us about use cases impacted by this feature.

Android 11 introduces the getHistoricalProcessExitReasons() method, which reports the reasons for any recent process terminations. Apps can use this method to gather crash diagnostic information, such as whether a process termination is due to ANRs, memory issues, or other reasons.

The getHistoricalProcessExitReasons() method returns an instance of the ApplicationExitInfo class, which contains information related to an app process's death. By calling getReason() on an instance of this class, you can determine why your app's process was killed. For example, a return value of REASON_CRASH indicates that an unhandled exception occurred in your app.

Requesting and checking for low latency support

Certain displays can perform graphics post-processing, such as some external displays and TVs. This post-processing improves the graphics but can increase latency. Newer displays which support HDMI 2.1 have an auto low latency mode (ALLM, also known as game mode), which minimizes latency by switching off this post-processing. For more details on ALLM, refer to the HDMI 2.1 specification.

A window can request that auto low latency mode be used, if it is available. ALLM is particularly useful for applications like games and videoconferencing, where low latency is more important than having the best possible graphics.

To toggle minimal post-processing on or off, call Window.setPreferMinimalPostProcessing(), or set the window's preferMinimalPostProcessing attribute to true. Not all displays support minimal post-processing; to find out if a particular display does support it, call the new method Display.isMinimalPostProcessingSupported().

Low-latency decoding in MediaCodec

Android 11 enhances MediaCodec to support low-latency decoding for games and other real-time apps. You can check whether a codec supports low-latency decoding by passing FEATURE_LowLatency to MediaCodecInfo.CodecCapabilities.isFeatureSupported().

To turn low-latency decoding on or off, do either of the following:

NDK image decoder

The NDK ImageDecoder API provides a standard API for Android C/C++ apps to decode images directly. App developers no longer need to use the framework APIs (via JNI) or bundle third-party image-decoding libraries. For more information, see the Image decoder developer guide.

Resource loaders

We're interested in hearing your feedback! Please take this short survey to let us know how you're using the feature. In particular, tell us about use cases impacted by this feature.

Android 11 introduces a new API that allows apps to dynamically extend how resources are searched and loaded. The new API classes ResourcesLoader and ResourcesProvider are primarily responsible for providing the new functionality. Together, they provide the ability to supply additional resources and assets, or modify the values of existing resources and assets.

ResourcesLoader objects are containers that supply ResourcesProvider objects to an app's Resources instance. In turn, ResourcesProvider objects provide methods to load resource data from APKs and resource tables.

One primary use case for this API is custom asset loading. You can pair an instance of the new API class DirectoryAssetsProvider with a ResourcesProvider to redirect the resolution of file-based resources and assets, searching a specific directory rather than the application APK. You can access these assets through the open() family of methods from the AssetManager API class, just like with assets bundled in the APK.

Updates to the ICU libraries

Android 11 updates the android.icu package to use version 66 of the ICU library, compared to version 63 in Android 10. The new library version includes updated CLDR locale data and a number of enhancements to internationalization support in Android.

Notable changes in the new library versions include the following:

  • Many formatting APIs now support a new return object type that extends FormattedValue.
  • The LocaleMatcher API is enhanced with a builder class, support for the java.util.Locale type, and a result class featuring additional data about a match.
  • Unicode 13 is now supported.

Neural Networks API 1.3

Android 11 expands and improves the Neural Networks API (NNAPI).

New operations

NNAPI 1.3 introduces a new operand type, TENSOR_QUANT8_ASYMM_SIGNED, to support TensorFlow Lite's new quantization scheme.

Additionally, NNAPI 1.3 introduces the QUANTIZED_LSTM operator.

New ML controls

NNAPI 1.3 introduces new controls to help machine learning run smoothly:

Biometric authentication strength

To help you control the level of security for your app's data, Android 11 introduces the BiometricManager.Authenticators interface. This interface defines the possible strengths of biometric hardware elements. The device manufacturer defines a specific strength for each element, such as BIOMETRIC_STRONG or BIOMETRIC_WEAK. These strength levels are defined on the Compatibility Definition page.

Your app can use the BiometricManager.Authenticators interface as follows:

  • The canAuthenticate() method has one argument: an integer or a bitwise combination of strength levels from BiometricManager.Authenticators. The overloaded version of canAuthenticate() that takes no arguments is deprecated as of Android 11.
  • The setAllowedAuthenticators() method requires your app's biometric authentication to rely on a biometric element that has one of the specified strength levels.
  • The canAuthenticate() and setAllowedAuthenticators() methods can both accept the Authenticators.DEVICE_CREDENTIAL argument, which allows for authentication using a PIN, pattern, or password. As a result, the related method setDeviceCredentialAllowed() is deprecated as of Android 11.
  • The ACTION_BIOMETRIC_ENROLL intent action invokes system settings and requests the user to enroll a biometric hardware element. You can provide the strength level as an extra.

Additionally, as of Android 11, the AuthenticationResult API allows you to check whether the user authenticated using biometric or device credentials. To check, call getAuthenticationType().

CallScreeningService updates

Starting in Android 11, a CallScreeningService can request information about the STIR/SHAKEN verification status (verstat) for incoming calls. This information is provided as part of the call details for incoming calls.

If a CallScreeningService holds the READ_CONTACTS permission, the app is notified when there are incoming calls from, or outgoing calls to, a number in the user's contacts.

Expanded camera support in Android emulator

Android 11 introduces improved Android Emulator camera capabilities. The added features include the following:

  • RAW capture
  • YUV reprocessing
  • Level 3 devices
  • Logical camera support

Mute notification sounds and vibrations during active capture

Beginning with Android 11, when actively using the camera, your app can mute only vibrations, both sounds and vibrations, or neither using setCameraAudioRestriction().

Wi-Fi Passpoint enhancements

Passpoint enables apps to automatically and silently perform authentication and connect to secure Wi-Fi hotspots. Apps that target API level 'R' and higher can use the following additional capabilities of Passpoint.

Expiration date enforcement and notification
Enforcing expiration dates on profiles allows the framework to avoid auto-connection to access points with expired credentials, which are destined to fail. This prevents airtime usage, and saves battery and backend bandwidth. It displays a notification to the user when their profile is in range and has expired.
FQDN Matching
Allow configuration of a named AAA domain separately from an Access Network Query Protocol (ANQP) fully qualified domain name (FQDN), using an Extension/Android node in PerProviderSubscription (PPS) Management Object (MO).
Self-signed private CAs
For Passpoint R1 Profiles, Android accepts private self-signed CAs for connection authentication.

Wi-Fi Suggestion API is expanded

Android 11 expands the Wi-Fi Suggestion API to increase your app's network management capabilities, including the following:

  • Connectivity management apps can manage their own networks by allowing disconnection requests.
  • Passpoint networks are integrated into the Suggestion API and can be suggested to the user.
  • Analytics APIs enable you to get information about the quality of your networks.

Chat Bubbles

Bubbles are now available to developers to help surface conversations across the system. Bubbles was an experimental feature in Android 10 that was enabled through a developer option -- in Android 11 this is no longer necessary.

There are a number of improvements to bubble performance, and users now have more flexibility in enabling and disabling bubbles from each app. For developers who implemented experimental support, there are a few changes to the APIs in Android 11: