Behavior changes: Apps targeting Android 11

The Android 11 platform includes behavior changes that may affect your app. The following behavior changes apply exclusively to apps that are targeting Android 11 or higher. If your app sets targetSdkVersion to "android-R", you should modify your app to support these behaviors properly, where applicable.

Be sure to also review the list of behavior changes that affect all apps running on Android 11.

Scoped storage

To give developers additional time for testing, apps that target Android 10 (API level 29) can still request the requestLegacyExternalStorage attribute. This flag allows apps to temporarily opt out of the changes associated with scoped storage, such as granting access to different directories and different types of media files. After you update your app to target Android 11, you cannot use requestLegacyExternalStorage to opt out of scoped storage.

Migrate data to directories that are visible when using scoped storage

If your app uses the legacy storage model and previously targeted Android 10 or lower, you might be storing data in a directory that your app cannot access when the scoped storage model is enabled. Before you target Android 11, migrate data to a directory that's compatible with scoped storage. In most cases, you can migrate data to your app-specific directory.

If you have data to migrate, it's possible to preserve the legacy storage model when a user upgrades to the new version of your app that targets Android 11. That way, the user retains access to app data that's stored in directories where your app had previously saved the data. To enable the legacy storage model for an upgrade, set the preserveLegacyExternalStorage attribute to true in your app's manifest.

Note: Most apps shouldn't need to use preserveLegacyExternalStorage. This flag is designed only for the situation where you migrated app data into a location that's compatible with scoped storage, and you want users to retain access to the data when updating your app. Using this flag makes it harder to test how scoped storage affects users of your app because when users update your app, it continues to use the legacy storage model.

If you use preserveLegacyExternalStorage, the legacy storage model remains in effect only until the user uninstalls your app. If the user installs or reinstalls your app on a device that runs Android 11, then your app cannot opt out the scoped storage model, regardless of the value of preserveLegacyExternalStorage.

Test scoped storage

To enable scoped storage in your app, regardless of your app's target SDK version and manifest flag values, enable the following app compatibility flags:

To disable scoped storage and use the legacy storage model instead, unset both flags.

To learn more about privacy changes related to storage in Android 11, see the Storage updates in Android 11 page.

Directory access restrictions

Change details

Change Name: RESTRICT_STORAGE_ACCESS_FRAMEWORK

Change ID: 141600225

How to toggle

As you test your app's compatibility with Android 11, you can toggle this change on or off using the following ADB commands:

adb shell am compat enable (141600225|RESTRICT_STORAGE_ACCESS_FRAMEWORK) PACKAGE_NAME
adb shell am compat disable (141600225|RESTRICT_STORAGE_ACCESS_FRAMEWORK) PACKAGE_NAME

For more information about the compatibility framework and toggling changes, see Test your app's compatibility with Android 11.

If your app targets Android 11 and uses the Storage Access Framework (SAF), you can no longer access certain directories using the ACTION_OPEN_DOCUMENT and ACTION_OPEN_DOCUMENT_TREE intent actions. To learn more about these changes, see the directory access restrictions section on the page that discusses privacy updates related to storage in Android 11.

Storage permissions

If your app targets Android 11, several behavior changes related to storage permissions take effect. To learn more about these changes, see the permissions section on the page that discusses privacy updates related to storage in Android 11.

Package visibility

Change details

Change Name: FILTER_APPLICATION_QUERY

Change ID: 135549675

How to toggle

As you test your app's compatibility with Android 11, you can toggle this change on or off using the following ADB commands:

adb shell am compat enable (135549675|FILTER_APPLICATION_QUERY) PACKAGE_NAME
adb shell am compat disable (135549675|FILTER_APPLICATION_QUERY) PACKAGE_NAME

For more information about the compatibility framework and toggling changes, see Test your app's compatibility with Android 11.

If your app targets Android 11 and needs to query or interact with other apps that are installed on the device, you might need to use the <queries> tag in the manifest file.

Note: Many common interactions don't require this new tag, including the following interactions:

  • The target app is your own app.
  • Your activity uses an implicit intent to start an activity.
  • Your app interacts with specific system packages, such as the media provider, that implement core Android functionality.
  • Another app expects a result from your app. For example, if another app makes a request to a content provider in your app, the system allows your app to see that other app.

To learn more about how to use this tag, see the package visibility privacy page.

Custom toast views are blocked

Change details

Change Name: CHANGE_BACKGROUND_CUSTOM_TOAST_BLOCK

Change ID: 128611929

How to toggle

As you test your app's compatibility with Android 11, you can toggle this change on or off using the following ADB commands:

adb shell am compat enable (128611929|CHANGE_BACKGROUND_CUSTOM_TOAST_BLOCK) PACKAGE_NAME
adb shell am compat disable (128611929|CHANGE_BACKGROUND_CUSTOM_TOAST_BLOCK) PACKAGE_NAME

For more information about the compatibility framework and toggling changes, see Test your app's compatibility with Android 11.

As of Android 11, custom toast views are deprecated. If your app targets Android 11, toasts that contain custom views are blocked when posted from the background. Custom toast views continue to work if you target an older version of Android, but their use is discouraged.

It's recommended that you use snackbars instead where possible. If your app's use case prevents you from using snackbars, such as when you need to send the user a message while your app is in the background, you can still use text toasts because they aren't restricted by the new behavior change.

To learn more about these changes, see Updates to toasts in Android 11.

Access to private directories

Android 11 expands a restriction related to accessing private data directories. Apps that target Android 11 can no longer access files in private data directories of any app, regardless of the other app's target SDK version.

Foreground service types

If your app targets Android 11 and runs a foreground service that uses data from the camera or microphone, update your app to use the new foreground service types introduced in Android 11.

MAC randomization

On apps that target Android 10 (API level 29) and lower, MAC randomization is per-SSID, because Passpoint can connect to different SSIDs for the same profile. On apps targeting Android 11 (API level 'R') and higher, MAC randomization for Passpoint networks is changed to per fully-qualified domain name (FQDN).

On apps that target API level 'R' and higher, non-privileged apps will not be able to access the device’s MAC address; only network interfaces with an IPv4 address will be visible. This impacts the getifaddrs() and NetworkInterface.getHardwareAddress() methods, as well as sending RTM_GETLINK netlink messages.

The following is a list of the ways that apps are affected by this change:

  • NetworkInterface.getHardwareAddress() returns null for every interface.
  • Apps cannot use the bind() function on NETLINK_ROUTE sockets.
  • The ip command does not return information about interfaces.

These changes enforce the guidance provided in Don’t work with MAC addresses.

Note that most developers should use the higher-level APIs of ConnectivityManager rather than the lower-level NetworkInterface/getifaddrs() APIs.

Firebase JobDispatcher and GCMNetworkManager

If your app targets API level 'R' or higher, Firebase JobDispatcher and GcmNetworkManager API calls are disabled on devices running Android 6.0 (API level 23) or higher. For migration information, see Migrating from Firebase JobDispatcher to WorkManager and Migrating from GCMNetworkManager to WorkManager.

Heap pointer tagging

Change details

Change Name: NATIVE_HEAP_POINTER_TAGGING

Change ID: 135754954

How to toggle

As you test your app's compatibility with Android 11, you can toggle this change on or off using the following ADB commands:

adb shell am compat enable (135754954|NATIVE_HEAP_POINTER_TAGGING) PACKAGE_NAME
adb shell am compat disable (135754954|NATIVE_HEAP_POINTER_TAGGING) PACKAGE_NAME

For more information about the compatibility framework and toggling changes, see Test your app's compatibility with Android 11.

Heap pointers now have a non-zero tag in the most significant byte (MSB). Applications that use pointers incorrectly, including those that modify the MSB, can now crash or experience other issues. This change is necessary to support future hardware with ARM Memory Tagging Extension (MTE) enabled. To learn more, see Tagged Pointers.

To disable this feature, see the allowNativeHeapPointerTagging manifest documentation.

Performant VPNs

Apps that target API level 'R' and higher or that are running on devices launched on API level 29 and higher can apply IKEv2/IPsec to VPNs for both user-configured and app-based VPNs.

The VPNs run native to the operating system, simplifying the code required to establish IKEv2/IPset VPN connections in an app.

Restricted read access to APN database

Change details

Change Name: APN_READING_PERMISSION_CHANGE_ID

Change ID: 124107808

How to toggle

As you test your app's compatibility with Android 11, you can toggle this change on or off using the following ADB commands:

adb shell am compat enable (124107808|APN_READING_PERMISSION_CHANGE_ID) PACKAGE_NAME
adb shell am compat disable (124107808|APN_READING_PERMISSION_CHANGE_ID) PACKAGE_NAME

For more information about the compatibility framework and toggling changes, see Test your app's compatibility with Android 11.

Apps that target Android 11 now require the Manifest.permission.WRITE_APN_SETTINGS privileged permission to read or access the Telephony provider APN database. Attempting to access the APN database without this permission generates a security exception.

Per-process network access control

Starting in Android 11, apps that deal with sensitive user data can grant per-process network access. By explicitly specifying which processes are allowed network access, you isolate all code that doesn’t need to upload data.

While not guaranteed to prevent your app from accidentally uploading data, it does provide a way for you to reduce the chance of bugs in your app causing a data leak.

The following shows a sample of a manifest file that uses the new functionality:

<processes>
    <process />
    <deny-permission android:name="android.permission.INTERNET" />
    <process android:process=":withoutnet1" />
    <process android:process="com.android.cts.useprocess.withnet1">
        <allow-permission android:name="android.permission.INTERNET" />
    </process>
    <allow-permission android:name="android.permission.INTERNET" />
    <process android:process=":withoutnet2">
        <deny-permission android:name="android.permission.INTERNET" />
    </process>
    <process android:process="com.android.cts.useprocess.withnet2" />
</processes>

Allow multiple installed Passpoint configurations with the same FQDN

Starting in Android 11, you can use PasspointConfiguration.getUniqueId() to get a unique identifier for a PasspointConfiguration object, which enables your app’s users to install multiple profiles with the same fully qualified domain name (FQDN).

This functionality is helpful when a carrier deploys more than one combination of Mobile Country Code (MCC) and Mobile Network Code (MNC) on their network, but has only a single FQDN. On Android 11 and higher, it is possible to install more than one profile with the same FQDN that will match the network as the Home provider when the user installs a SIM with either MCC or MNC.