New version system adaptation: Compatibility changes in Android 12

With the Android 12 official version , more and more users will upgrade to the latest version. Android 12 brings a large number of new APIs and functional updates, but also brings changes in platform compatibility. We recommend that developers give priority to testing current applications and make compatibility updates. This ensures that users have a good experience when they update their devices to Android 12.

This article will highlight the biggest compatibility changes in Android 12 and share some advice on how to make the transition to the latest version of the system smooth for users. In addition, we'll share stories and advice from leading apps to help you understand how other developers are taking advantage of Android 12's features, and how they can be borrowed from your own apps.

If you prefer to see this through video, check it out here:

https://www.bilibili.com/video/BV13L411c7M9/?aid=465601907&cid=481166217&page=1

△ New version system adaptation: Compatibility changes in Android 12

Android 12

Compatibility changes fall into two main categories, those that affect all running apps by default, and those that only affect apps based on their declared target SDK level. For convenience, this article will annotate the change title to help you better understand how the corresponding change affects your app.

Android 12 delivers a visual refresh by leaps and bounds with a new personalized Material Design. We're always on the lookout for simplifying and improving existing experiences and helping you build beautiful, secure, and performant apps that meet user needs. To this end, we focus on optimization in three areas: user interface, performance, and privacy. This article will mainly introduce the changes in the user interface and performance of Android 12.

User interface related changes

Application opening page (affects all applications)

Starting with Android 12, the system will use the new default splash screen for both cold and warm startup applications. The splash page consists of the app's launch icon and the theme's windowBackground, and shows a smooth, fluid transition animation when it starts up.

△ The default opening page in Android 12

This new experience is available for all apps running on Android 12. If your app implements a custom splash page, you will need to migrate to the new SplashScreen API. We recommend using Jetpack's SplashScreen library for backward compatibility to provide a consistent look and feel across all Android versions.

Since the new splash page is fully customizable, we recommend removing it entirely, even if your existing splash page is used for routing. This will avoid duplication of splash pages and reduce loading times.

For a detailed adaptation process, please refer to the migration guide Android developer website.

Custom notification (only affects apps with targetSdkVersion 31)

Android 12 changes the look and behavior of fully customizable notifications, making them visually consistent and easy to navigate, and providing users with a detectable, familiar notification expanded state.

△ Android 12 notification style

Previously, custom notifications could use the entire notification area and provide their own layout and styling. For apps targeting Android 12, notifications with custom content views will no longer use the entire notification area, instead using the standard template.

△ Comparison of areas available for custom notifications before and after Android 12

This template ensures that custom notifications are decorated the same as other notifications in all states, such as icon, app name, expanded and collapsed state IDs. This change affects apps that use custom Notification.Style subclasses or use Notification.Builder methods to set custom content views. If your app is using fully custom notifications, be sure to test them for compatibility with the new template.

△ API of the affected custom content view

Gesture Navigation in Immersive Mode (affects all apps)

Android 12 also integrates existing behaviors to make it easier for users to perform gesture navigation commands in immersive mode. System gestures respond instantly even in immersive mode. The two behaviors BEHAVIOR_SHOW_BARS_BY_TOUCH and BEHAVIOR_SHOW_BARS_BY_SWIPE are now deprecated and replaced by the new BEHAVIOR_DEFAULT behavior. The BEHAVIOR_DEFAULT behavior allows the user to perform gesture navigation with a single swipe, compared to two swipes on Android 11. Even when developing a full screen game experience, users can still be protected from accidental touch gestures in immersive mode by using the BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE flag.

△ Gesture navigation in immersive mode in Android 12

Performance related changes

foreground service (only affects applications whose targetSdkVersion is 31)

Foreground services allow the Android system to ensure that resources are prioritized for user-initiated time-consuming tasks, but they are often abused. We found that almost half of all foreground services were started from the background, which caused a number of issues, including rapid battery drain and users being bothered by unexpected foreground service notifications. Therefore, starting from Android 12, starting foreground services from the background will be prohibited, and there will be restrictions on starting foreground services. The foreground service can be started in the following situations:

• Visible Activity or Window
• User actions such as notifications, widgets, etc.
• specific broadcasts and callbacks
• Services of type STICKY can be restarted if they crash or stop due to low memory

For a complete list of exemptions from foreground service startup restrictions, see the Android Developers website - services .

Earlier this year, we introduced expedited tasks in Jetpack's WorkManager library. These low-latency tasks can be called from the foreground or background and execute immediately. These tasks can run in low power mode. We encourage developers to use these tasks instead of starting foreground services whenever possible.

Precise alarm clock permission (only affects apps with targetSdkVersion 31)

In most cases, apps should use coarse-precision alarms, which have the advantage of saving power. In special cases, such as alarms and timers, precise alarms can be used. Android 12 adds a new manifest permission, SCHEDULE_EXACT_ALARM, which allows users to view and control apps with this permission. In addition, a new API has been added - canScheduleExactAlarms(), which you can use to check the permission status of your application.

Notification trampolines (Notification trampolines, only affects apps with targetSdkVersion 31)

Some apps use intermediate components such as broadcast receivers or services when handling user clicks on notifications. These components are called notification trampolines. They often cause delays and interrupt user flow. Apps targeting Android 12 will not be able to launch from these trampolines. activity. This new limit helps reduce the delay in launching apps from notifications. We encourage deprecating the notification trampoline and launching the target activity directly from the notification. For example, after deprecating the notification trampoline, the Google Photos app launched 34% faster. If your app uses a notification trampoline, use the following adb command to see which components are launched when the user interacts with the notification:

$ adb shell dumpsys activity service \ 
com.android.systemui/.dump.SystemUIAuxiliaryDumpService

△ Use this command to view the components that are started when the user interacts with the notification

Application link (only affects applications with targetSdkVersion of 31)

Android supports the concept of app links, which allow HTTP URLs to link directly to installed apps. This completely bypasses the disambiguation dialog and improves the user experience by eliminating disagreements in the user journey. The difference between app linking and deep linking is that app linking can only handle HTTP mode, while deep linking can handle any mode.

Unlike previous versions, Android 12 will always open the default browser for unverified links. This is probably the most important change in App Links behavior. Android 12 also introduces per-link verification, so if there is any server-side integration or misconfiguration, it will be limited to links that don't pass verification, you can use the new DomainVerificationManager API to check the domain verification status and take the user to the " Settings" to approve the domain name used by the app. For more information, see the Android Developers Site - Verify Android Apps link .

△ Use app links to bypass disambiguation dialogs and go directly to installed apps

Compatibility Framework Tools

Now that we've seen the new features and changes in Android 12, let's take a look at the tests and tools to make apps compatible. In Android 11 we introduced the Compatibility Framework tool to make it easier to test and debug apps against changes. With these tools you can individually turn a breaking change on and off and assess its impact on your application. This way, you can isolate and test only one behavior change at a time, or easily enable the corresponding change for the targetSDK.

△ Developer Options > App Compatibility Changes

You can use developer options, logcat, or the adb command to check for currently enabled behavior changes. For each behavior change, the system outputs a logcat message similar to this when the app first calls the affected API:

D CompatibilityChangeReporter: Compat change id reported: 170668199 ;
UID 10265; state: ENABLED

△ Logcat is an example of the output of a change

You can use the following adb command to list all compatibility changes (both enabled and disabled) known to the system and their current enablement. Each change in the list has a name, a change ID for reference, and an enabled/disabled status.

$ adb shell dumpsys platform-compat

△ Use the adb command to list all compatibility changes known to the system

Changes for a package can also be turned on or off using the following adb commands:

$ adb shell am compat enable|disable|reset <CHANGE_ID | CHANGE_NAME> <PACKAGE_NAME>

△ Use the adb command to set changes for a single application

No need to change targetSdkVersion or recompile the app in basic tests, the Android platform automatically adjusts its internal logic. Because changes can be turned on or off individually, you can isolate tests one by one, debug behavioral changes, or disable individual changes that cause problems.

Note that since only debuggable app changes can be turned on or off. So if you don't see your app in the compatibility framework make sure to set the app to be debuggable in the manifest:

<application
    android:debuggable="true">

△ Set the application as debuggable in the manifest file

Remember that on a signed Android release, you cannot modify the enabled state of changes that affect all apps. Android 12 adds new adb commands to test and verify app links for apps. You can use these commands to manually verify the link on the device, or add it to your continuous integration toolchain.

// 清除应用任何已经验证的状态：
$ adb shell pm set-app-links --package PACKAGE_NAME 0 all
 
// 开始验证测试：
$ adb shell pm verify-app-links --re-verify PACKAGE_NAME
 
// 查看测试结果：
$ adb shell pm get-app-links PACKAGE_NAME

△ Use these adb commands to test app links in Android 12

Be sure to try Android Studio Arctic Fox for development and testing. We've added lint checks to help you spot where your code might be affected by changes in Android 12. Examples include custom splash pages, rough location permissions for precise location usage, media formats, and more. The first thing to do, of course, is to set up the Android 12 SDK.

Developer Case

Now we will show some successful cases that developers have adapted to Android 12. Thanks to Android 12, their users can take advantage of this new experience.

Nearby device permissions (only affects apps with targetSdkVersion 31)

Withings' HealthMate app allows users to connect and sync Withings devices via Bluetooth. Android 12 introduces a new permission that separates Bluetooth scanning from location permissions.

△ HealthMate app applies for nearby device permissions

For us, nearby device permissions are one of the most important changes in Android 12.

Withings HealthMate

On a privacy level, it is difficult to explain to end users how location permissions relate to Bluetooth. For several years, the team at Withings had to invest in customer service topics and tutorials so users could understand why the app needed location permissions to scan for Bluetooth. Even with adequate explanations, the team received negative feedback for applying for location permissions.

In contrast, the Nearby Device permission is more effective. Because it only asks for permission when scanning and connecting. Withings engineers have some suggestions:

• Abstract the logic of checking and requesting new permissions. This helps control entry points and minimize testing effort;
• Unit test all permission checks on all supported Android versions;
• Use a real Android device and test different upgrade scenarios to ensure the app works properly;
• If an app was granted location permission on previous Android versions, when the user upgrades to Android 12, the app will automatically be granted the Nearby Device permission.

To use the new nearby devices permission, the BLUETOOTH_SCAN permission must be declared in the manifest file:

<uses-permission
    android:name="android.permission.BLUETOOTH_SCAN"
    android:usesPermissionFlags="neverForLocation" />

△ Permissions should be declared in the manifest file when scanning for nearby devices

This is a runtime permission that, in addition to being declared in the manifest, the app must also check for and request this permission at runtime before starting to scan the device. You can indicate that you do not intend to use the scan results to obtain the user's location by declaring the usesPermissionFlags attribute as neverForLocation.

If you only need to connect to the device, you can declare the BLUETOOTH_CONNECT permission:

<uses-permission
    android:name="android.permission.BLUETOOTH_CONNECT" />

△ Permissions should be declared in the manifest file when connecting the device

Overscroll Effect (Overscroll Effect, affects all apps)

Most apps on Android 12 will have a new overscroll stretch effect. Some beta users with Android 12 noticed a strange effect when scrolling through messages in the Signal app:

△ Strange effects in the Signal app

In Signal's case, the app supports custom backgrounds. The app uses a masking algorithm that penetrates the interface level. Whenever content is laid out or scrolled, the Signal app builds up a list of message bubble projections on the screen. The app then uses these projections to create a mask, which Applies to the given gradient or solid color.

The engineering team quickly came up with a solution utilizing RecyclerView.ItemDecoration. Fixing the overscroll issue early allows the Signal app to provide the experience users expect on newer devices without compromising performance.

△ Signal after fixing the effect of overscrolling

We fixed the overscrolling issue in time for the official version of Android 12 and provided users with a unified experience.

Signal Private Messenger

The Signal team made some recommendations:

• Note the blending mode and how it works as an additional layer. Android 12 overscrolling uses additional layers to render stretch effects, which can produce different results with different blending algorithms;
• Make sure the background is rendered by the RecyclerView;
• Before release, perform a full QA and address user feedback on Android 12 compatibility.

The Signal app is an example of a delightful user experience. Fortunately, Signal Private Messenger for Android is open source, and you can view its fix code GitHub

Summary

In this article, we describe the most important changes Android 12 brings to developers and users, and make some recommendations:

• Android 12 brings noticeable visual updates
• Test your app with the tools and suggestions provided
• Get inspired by other developers

For more changes, see the Android Developers site - Android 12 .

Most importantly, remember to test your app and confirm its compatibility with Android 12. Many developers have done this, and now is the time to prepare for these changes and deliver a great user experience. We look forward to seeing your app on Android 12.

You are welcome to to submit feedback to us, or share your favorite content and found problems. Your feedback is very important to us, thank you for your support!