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.

Privacy

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

Compressed resource file

Apps that target Android 11 (API level 'R') or higher can not be installed if they contain a compressed resources.arsc file or if this file is not aligned on a 4-byte boundary. This file cannot by memory-mapped by the system if either of these conditions is present. Resources tables that cannot be memory-mapped must be read into a buffer in RAM resulting in unnecessary memory pressure on the system and greatly increased device RAM usage.

Connectivity

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.

Security

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.

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.

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.

APK Signature Scheme v2 now required

Apps that target Android 11 (API level 'R') that are currently only signed using APK Signature Scheme v1 must now also be signed using APK Signature Scheme v2 or higher. Users can't install or update apps that are only signed with APK Signature Scheme v1 on devices that run Android 11.

To verify that your app is being signed with APK Signature Scheme v2 or higher, you can use either Android Studio, or the apksigner tool on the command line.

Firebase

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.

Implicit media capture intents and location metadata

Starting in Android 11, only pre-installed system camera apps can respond to the following intent actions:

If more than one pre-installed system camera app is available, the system presents a dialog for the user to select an app. If you want your app to use a specific third-party camera app to capture images or videos on its behalf, you can make these intents explicit by setting a package name or component for the intent.

To include location metadata, your app must declare ACCESS_MEDIA_LOCATION in addition to the ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION runtime permissions.