Features and APIs Overview

Android 11 introduces great new features and APIs for developers. The sections below help you learn about features for your apps and get started with the related APIs.

For a detailed list of new, modified, and removed APIs, read the API diff report. For details on new APIs 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.

New experiences

Screens

Better support for waterfall displays

Android 11 provides several APIs to support waterfall displays, displays which wrap around the edge of the device. These displays are treated as a variant of displays with display cutouts. The existing DisplayCutout.getSafeInset…() methods now return the safe inset to avoid waterfall areas as well as cutouts. To render your app content in the waterfall area, do the following:

  • Call DisplayCutout.getWaterfallInsets() to get exact dimensions of the waterfall inset.

  • Set the window layout attribute layoutInDisplayCutoutMode to LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS to allow the window to extend into the cutout and waterfall areas on all edges of the screen. You must make sure that no essential content is in the cutout or waterfall areas.

Hinge angle sensor and foldables

Android 11 makes it possible for apps running on devices with hinge-based screen configurations to determine the angle of the hinge by providing a new sensor with TYPE_HINGE_ANGLE, and a new SensorEvent that can monitor the hinge angle and provides a measurement in degrees between two integral parts of the device. You can use these raw measurements to perform granular animations as the user manipulates the device.

Even though some kinds of apps (such as launchers and wallpapers) may find it useful to know the exact hinge angle, most apps should use the Jetpack Window Manager library to retrieve the device posture by calling DeviceState.getPosture().

Alternatively, your app can call registerDeviceStateChangeCallback() to be informed when the DeviceState changes and react when the posture changes.

Responding to the device posture is safer and more reliable, due to the many different window and device configurations currently in the market and coming in the future.

Conversations

Conversation improvements

Android 11 makes a number of improvements to the way conversations are handled. Conversations are real-time, bidirectional communications between two or more people. These conversations are given special prominence, and users have several new options in how to interact with them.

For more information about conversations and how your app can support them, see Conversations.

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:

Data sharing with content capture service

Starting in Android 11, your app can share data with the device's content capture service. This capability makes it easier for a device to deliver in-context intelligence, such as showing the name of a song that's currently playing in the user's environment or showing relevant travel information when the user is near a station or airport.

To make data from your app available to the content capture service, call the shareData() method on an instance of ContentCaptureManager. If the system accepts the data-sharing request, your app receives a write-only file descriptor to share with the content capture service.

5G visual indicators

On Android 11 (API level 'R') and higher, apps with android.Manifest.permission.READ_PHONE_STATE permission can request telephony display information updates through PhoneStateListener.onDisplayInfoChanged(). This includes radio access technology information for marketing and branding purposes.

Various 5G icon display solutions for different carriers are provided by this new API. The supported technologies include the following:

  • LTE
  • LTE with carrier aggregation (LTE+)
  • Advanced pro LTE (5Ge)
  • NR (5G)
  • NR on millimeter-wave cellular bands (5G+)

Privacy

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

Security

Biometric authentication updates

To help you control the level of security for your app's data, Android 11 provides several improvements to biometric authentication.

Authentication types

Android 11 introduces the BiometricManager.Authenticators interface, which defines the types of authentication that the BiometricManager class supports:

BIOMETRIC_STRONG
Authentication using a hardware element that satisfies the Strong strength level as defined on the Compatibility Definition page.
BIOMETRIC_WEAK
Authentication using a hardware element that satisfies the Weak strength level as defined on the Compatibility Definition page.
DEVICE_CREDENTIAL
Authentication using a screen lock credential – the user's PIN, pattern, or password.

To define the types of biometric authentication that your app accepts, pass an authentication type or a bitwise combination of types into the setAllowedAuthenticators() method. For example, if your app accepts either a "strong" hardware element or a screen lock credential, pass in BIOMETRIC_STRONG | DEVICE_CREDENTIAL.

To check whether the necessary authentication elements are available, pass the same bitwise combination of types into the canAuthenticate() method. If necessary, invoke the ACTION_BIOMETRIC_ENROLL intent action. In the intent extra, provide the set of authenticators that your app accepts. This intent prompts the user to register credentials for an authenticator that your app accepts.

After the user authenticates, you can check whether the user authenticated using a device credential or a biometric credential by calling getAuthenticationType().

Additional support for auth-per-use keys

Android 11 provides more support for auth-per-use keys within the BiometricPrompt class. Such a key requires the user to present either a biometric credential, a device credential, or either credential each time your app needs to access data that's guarded by that key. Auth-per-use keys are useful for high-value transactions, such as making a large payment or updating a person's health records.

To associate a BiometricPrompt object with an auth-per-use key, add code similar to the following:

Kotlin

val authPerOpKeyGenParameterSpec =
        KeyGenParameterSpec.Builder("myKeystoreAlias", key-purpose)
    // Accept either a biometric credential or a device credential.
    // To accept only one type of credential, include only that type as the
    // 2nd argument.
    .setUserAuthenticationParameters(0 /* duration */,
            KeyProperties.AUTH_BIOMETRIC_STRONG or
            KeyProperties.AUTH_DEVICE_CREDENTIAL)
    .build()

Java

KeyGenParameterSpec authPerOpKeyGenParameterSpec =
        new KeyGenParameterSpec.Builder("myKeystoreAlias", key-purpose)
    // Accept either a biometric credential or a device credential.
    // To accept only one type of credential, include only that type as the
    // 2nd argument.
    .setUserAuthenticationParameters(0 /* duration */,
            KeyProperties.AUTH_BIOMETRIC_STRONG |
            KeyProperties.AUTH_DEVICE_CREDENTIAL)
    .build();

Deprecated methods

Android 11 deprecates the following methods:

  • The setDeviceCredentialAllowed() method.
  • The setUserAuthenticationValidityDurationSeconds() method.
  • The overloaded version of canAuthenticate() that takes no arguments.

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.

Performance and quality

Wireless debugging

Android 11 supports deploying and debugging your app wirelessly from your workstation via Android Debug Bridge (adb). For example, you can deploy your debuggable app to multiple remote devices without physically connecting your device via USB and contending with common USB connection issues, such as driver installation.

To use wireless debugging, you need to pair your device to your workstation using a pairing code. Your workstation and device must be connected to the same wireless network. To connect to your device, follow these steps:

wireless adb pairing dialog
  1. On your workstation, update to the latest version of the SDK Platform-Tools.
  2. On the device, enable developer options.
  3. Enable the Wireless debugging option.
  4. On the dialog that asks Allow wireless debugging on this network?, click Allow.
  5. Select Pair device with pairing code. Take note of the pairing code, IP address, and port number displayed on the device (see image).
  6. On your workstation, open a terminal and navigate to android_sdk/platform-tools.
  7. Run adb pair ipaddr:port. Use the IP address and port number from step 5.

  8. When prompted, enter the pairing code that you received in step 5. A message should indicate that your device has been successfully paired.

    Enter pairing code: 482924
Successfully paired to 192.168.1.130:37099 [guid=adb-235XY]

  9. (For Linux or Microsoft Windows only) Run adb connect ipaddr:port. Use the IP address and port under Wireless debugging (see image below).

    wireless adb IP and port number

ADB Incremental APK installation

Installing large (2GB+) APKs on a device can take a long time, even if only a small change is made to an app. ADB (Android Debug Bridge) Incremental APK installation accelerates this process by installing enough of the APK to launch the app while streaming the remaining data in the background. adb install will use this feature automatically if it is supported by the device and you have the latest SDK Platform-Tools installed. If it is not supported, the default installation method is silently used.

Use the following adb command to use the feature. If the device does not support incremental installation, the command fails and prints a verbose explanation.

adb install --incremental

Before running an ADB incremental APK install, you must sign your APK and create an APK Signature Scheme v4 file. The v4 signature file must be placed next to the APK for this feature to work.

Error detection using the native memory allocator

GWP-ASan is a native memory allocator feature that helps find use-after-free and heap-buffer-overflow bugs. You can enable this feature globally or for specific subprocesses of your app. To learn more, see the GWP-Asan guide.

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 following new operations:

  • QUANTIZED_LSTM
  • IF
  • WHILE
  • ELU
  • HARD_SWISH
  • FILL
  • RANK

New ML controls

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

NDK Thermal API

When devices get too warm, they may throttle the CPU and/or GPU, and this can affect apps in unexpected ways. Apps or games that incorporate complex graphics, heavy computation, or sustained network activity are more likely to encounter issues.

Use the NDK Thermal API in Android 11 to monitor temperature changes on the device, and then take action to maintain lower power usage and cooler device temperature. This API is similar to the Java Thermal API; you can use it to receive notifications for any thermal status change or to poll the current status directly.

Text and input

Improved IME transitions

Android 11 introduces new APIs to improve transitions for input method editors (IMEs), such as on-screen keyboards. These APIs make it easier to adjust your app's content in synchronization with the IME's appearance and disappearance, and with other elements like the status and navigation bars.

To show an IME while any EditText has the focus, call view.getInsetsController().show(Type.ime()). (You can call this method on any view in the same hierarchy as the focused EditText, you don't have to call it on the EditText specifically.) To hide the IME, call view.getInsetsController().hide(Type.ime()). You can check whether an IME is currently visible by calling view.getRootWindowInsets().isVisible(Type.ime()).

To synchronize your app's views with the appearance and disappearance of the IME, set a listener on a view by providing a WindowInsetsAnimation.Callback to View.setWindowInsetsAnimationCallback(). (You can set this listener on any view, it doesn't have to be an EditText.) The IME calls your listener's onPrepare() method, then it calls onStart() at the beginning of the transition. It then calls onProgress() at each progression in the transition. When the transition has finished, the IME calls onEnd(). At any point in the transition, you can find out how much progress the transition has made by calling WindowInsetsAnimation.getFraction().

For an example of how to use these APIs, see the new WindowInsetsAnimation code sample.

Controlling the IME animation

You can also take control of the IME animation, or the animation of another system bar like the navigation bar. To do this, first call setOnApplyWindowInsetsListener() to set a new listener for window inset changes:

Kotlin

rootView.setOnApplyWindowInsetsListener { rootView, windowInsets ->
    val barsIme = windowInsets.getInsets(Type.systemBars() or Type.ime())
    rootView.setPadding(barsIme.left, barsIme.top, barsIme.right, 
                          barsIme.bottom)

      // We return the new WindowInsets.CONSUMED to stop the insets being
      // dispatched any further into the view hierarchy. This replaces the
      // deprecated WindowInsets.consumeSystemWindowInsets() and related
      // functions.
    WindowInsets.CONSUMED
}

Java

mRoot.setOnApplyWindowInsetsListener(new View.OnApplyWindowInsetsListener() {
   @Override
   public WindowInsets onApplyWindowInsets(View v, WindowInsets insets) {

       Insets barsIME = insets.getInsets(Type.systemBars() | Type.ime());
       mRootView.setPadding(barsIme.left, barsIme.top, barsIme.right,
                             barsIme.bottom);

      // We return the new WindowInsets.CONSUMED to stop the insets being
      // dispatched any further into the view hierarchy. This replaces the
      // deprecated WindowInsets.consumeSystemWindowInsets() and related
      // functions.
       return WindowInsets.CONSUMED;
   }
});

To move the IME or other system bar, call the controller's controlWindowInsetsAnimation() method:

Kotlin

view.windowInsetsController.controlWindowInsetsAnimation(
       Type.ime(),
       1000,
       LinearInterpolator(),
       cancellationSignal,
       object : WindowInsetsAnimationControlListener() {
           fun onReady(controller: WindowInsetsAnimationController,
                         types: Int) {
               // update IME inset
             controller.setInsetsAndAlpha(Insets.of(0, 0, 0, inset),
                           1f /* alpha */, 0.1 /* fraction progress */)
           }
       }
);

Java

mRoot.getWindowInsetsController().controlWindowInsetsAnimation(
       Type.ime(), 1000, new LinearInterpolator(), cancellationSignal,
       new WindowInsetsAnimationControlListener() {
           @Override
           public void onReady(
                   @NonNull WindowInsetsAnimationController controller,
                   int types
                   ) {
                   // update IME inset
                   controller.setInsetsAndAlpha(Insets.of(0, 0, 0, inset),
                           1f /* alpha */, 0.1 /* fraction progress */);
           }

           @Override
           public void onCancelled() {}
       });

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.

Media

Allocating MediaCodec buffers

Android 11 includes a new MediaCodec APIs that gives apps more control when allocating input and output buffers. This lets your app manage memory more efficiently.

New classes:

New methods:

In addition, the behavior of two methods in MediaCodec.Callback() have changed:

onInputBufferAvailable()
Instead of calling MediaCodec.getInputBuffer() and MediaCodec.queueInputBuffer() with the index, if configured to use the Block Model API, apps should use MediaCodec.getQueueRequest with the index, attaching a LinearBlock/HardwareBuffer to the slot.
onOutputBufferAvailable()
Instead of calling MediaCodec.getOutputBuffer() with the index, apps may use MediaCodec.getOutputFrame() with the index to get the OutputFrame object with more information and LinearBlock/HardwareBuffer buffers.

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:

OpenSL ES is deprecated

Starting with NDK r21b beta 2 the OpenSL ES API is deprecated. You should use Oboe instead.

The platform still supports OpenSL ES for existing apps. However, a build warning appears when using OpenSL ES with a minSdkVersion of 30 or higher.

New AAudio function AAudioStream_release()

The function AAudioStream_close() releases and closes an audio stream at the same time. This can be dangerous. If another process tries to access the stream after it's been closed, the process will crash.

The new function AAudioStream_release() releases the stream but does not close it. This frees its resources and leaves the stream in a known state. The object persists until you call AAudioStream_close().

MediaParser API

MediaParser is a new low level API for media extraction. It is more flexible than MediaExtractor and provides additional control over media extraction functionality.

Connectivity

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.
Allow multiple profiles with identical FQDN
Allow to install multiple Passpoint profiles with identical FQDN. The FQDN is not used as a key for profiles. Existing Passpoint APIs that require FQDN, such as remove, apply the request to all matching profiles with the same FQDN.
Allow to install profiles without a Root CA certificate
Profiles without a Root CA certificate are allowed. In this case, the system verifies the AAA server certificates against the public Root CA certificates installed in the trust store.
Improved Home and Roaming provider matching
The system matches Home or Roaming networks regardless of the advertised authentication method. Additionally, added support for Home matching for OtherHomePartners and HomeOIList lists.

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.

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.

GNSS antenna support

Android 11 introduces the GnssAntennaInfo class, which makes it possible for your app to make more use of centimeter-accuracy positioning that the Global Navigation Satellite System (GNSS) can provide. After the user grants your app the ACCESS_FINE_LOCATION permission, your app can access the following details related to the GNSS antenna:

  • Phase center offset (PCO) coordinates
  • Phase center variation (PCV) corrections
  • Signal gain corrections

To determine whether a device can provide GNSS antenna information to your app, call hasGnssAntennaInfo().

Privacy considerations

  • The GNSS antenna can identify only the device model, not an individual device.
  • Use of the GnssAntennaInfo class requires the ACCESS_FINE_LOCATION permission.

Graphics

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.

Frame rate API

Android 11 provides an API that enables apps to inform the system of their intended frame rate, to reduce judder on devices that support multiple refresh rates. For information on how to use this API, see the Frame rate guide.

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

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>

ANGLE for OpenGL ES

You can run non-core apps using ANGLE to evaluate performance and decide whether or not a particular app should use ANGLE rather than the native OpenGL ES drivers. For instructions see Using ANGLE for OpenGL ES.

Images and camera

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

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

Better support for HEIF images with multiple frames

Beginning with Android 11, if you call ImageDecoder.decodeDrawable() and pass an HEIF image containing a sequence of frames (such as an animation or a burst photo), the method returns an AnimatedImageDrawable containing the entire image sequence. On earlier versions of Android, the method returned a BitmapDrawable of just a single frame.

If the HEIF graphic contains multiple frames that are not in a sequence, you can retrieve an individual frame by calling MediaMetadataRetriever.getImageAtIndex().

Accessibility

Updates for accessibility service developers

If you create a custom accessibility service, you can use the following features in Android 11:

  • The user-facing explanation of an accessibility service now allows for HTML and images in addition to plain text. This flexibility makes it easier to explain to end-users what your service does and how it can help them.
  • To work with a description of a UI element's state that's more semantically meaningful than contentDescription, call the getStateDescription() method.
  • To request that touch events bypass the system's touch explorer, call setTouchExplorationPassthroughRegion(). Similarly, to request that gestures bypass the system's gesture detector, call setGestureDetectionPassthroughRegion().
  • You can request IME actions, such as "enter" and "next", as well as screenshots of windows that don't enable the FLAG_SECURE flag.

Additional features

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 ActivityManager.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. Additionally, you can use the new setProcessStateSummary() method to store custom state information for later analysis.

The getHistoricalProcessExitReasons() method returns instances 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. If your app needs to ensure uniqueness for exit events, it can maintain an app-specific identifier, such as a hash value based on the timestamp from the getTimestamp() method.

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 use loadFromDirectory() to create a ResourcesProvider that redirects the resolution of file-based resources and assets, causing it to search 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.

APK signature scheme v4

Android 11 adds support for APK Signature Scheme v4. This scheme produces a new kind of signature in a separate file (apk-name.apk.idsig) but is otherwise similar to v2 and v3. No changes are made to the APK. This scheme supports ADB incremental APK installation, which speeds up APK install.

Dynamic intent filters

In order to receive intents, an app must declare at compile time which types of data it is able to receive by defining an intent filter in the app manifest. In Android 10 and lower, apps have no way of changing their intent filters at runtime. This is a problem for virtualization apps (such as virtual machines and remote desktops) because they have no way of knowing exactly what software the user will install inside them.

Android 11 introduces MIME groups, a new manifest element which allows an app to declare a dynamic set of MIME types in an intent filter and modify it programmatically at runtime. To use a MIME group, include a data element in your app manifest with the new android:mimeGroup attribute:

<intent-filter>
  <action android:name="android.intent.action.SEND"/>
  <category android:name="android.intent.category.DEFAULT"/>
  <data android:mimeGroup="myMimeGroup"/>
</intent-filter>

The value of the android:mimeGroup attribute is an arbitrary string ID that identifies the MIME group at runtime. You can access and update the contents of a MIME group by passing its ID to the following new methods in the PackageManager API class:

When you add a MIME type to a MIME group programmatically, it functions exactly the same as a static MIME type explicitly declared in the manifest.

Autofill enhancements

Android 11 introduces improvements for autofill services.

Hint identifiers in AssistStructure.ViewNode

It is often useful for autofill services to compute a signature hash for a view based on the view's properties. The view hint is a particularly good property to include when computing a signature hash, but the hint string might change with the phone's locale. To solve this problem, Android 11 expands AssistStructure.ViewNode with a new getHintIdEntry() method, which returns the resource identifier for a view's hint text. This method provides a locale-independent value that you can use to compute signature hashes.

Datasets shown events

To help autofill services improve their suggestions, Android 11 provides a way to identify cases where an autofill service presented datasets but the user did not select any of them. In Android 11, FillEventHistory reports a new TYPE_DATASETS_SHOWN event type. FillEventHistory logs an event of this type whenever the autofill service presents one or more datasets to the user. Autofill services can use these events in conjunction with the existing TYPE_DATASET_SELECTED event to determine whether the user selected any of the provided autofill options.