☰
🔍
☰
🔍
06 July 2020
Posted by Diana Wong, Product Manager, Android
This week in 11 Weeks of Android, we’re highlighting Android 11 Compatibility, a theme that’s important for all developers. For Android, the term app compatibility means that your app runs properly on a specific version of Android, typically the latest version.
We’re sharing resources to help you with compatibility testing here, and you can follow Android Developers on Twitter and Youtube to catch helpful content and materials in this area all this week!
With each release, we’re working to reduce the work you’ll need to do to get your apps ready. In Android 11, we’ve added new processes, developer tools, and release milestones to minimize the impact of platform updates and make it easier for apps to stay compatible.
You’ll hear more about these topics throughout the week. To get things started, read on to learn more about how we're making it easier to test and debug your app in Android 11.
Testing your app for a new Android release can be a challenging task, especially when your app might be affected by multiple platform changes. Many questions can come up:
targetSDKVersion, and what’s the easiest way to do so?
We've gotten a lot of great feedback from our developer community about these and other questions. In Android 11, we've added new tools to the platform and new features to Android Studio that can make the testing process a little easier for you.
Like previous releases, Android 11 includes some changes in the Android platform that may impact your apps. Although these changes are critical to improve the platform, we try to minimize the immediate change to your apps by putting as many changes as possible behind the platform's latest targetSDKVersion. In Android 11, we've also added many of these platform changes to a new compatibility framework.
When a change is part of the compatibility framework, you can access new developer tools that help you test and debug your app against that change.
For instance, changes that are part of the compatibility framework are toggleable, so you can force-enable or disable the changes individually, either from a device's developer options or using ADB (Android Debug Bridge). The Android platform automatically adapts its internal API logic, so you don't need to change your targetSDKVersion or recompile your app to perform basic testing. In addition, you can isolate individual changes from each other to lower the amount of time it takes to discover and debug issues in your app.
Before you start toggling changes on or off, you should read through the lists of behavior changes to determine which changes might affect your app. Changes that are part of the compatibility framework have a corresponding Change ID and Change Name listed before the description of the change.
Generally, we recommend that you start testing with behavior changes that affect all apps because those changes can potentially affect your app regardless of targetSDKVersion. However, let's take a look at a change that is gated by targetSDKVersion so that you can see how to test against these changes without recompiling your app with a different target SDK.
Take a look at the change to background location access. This change affects apps that request all-the-time access to background location. If your app is affected by this change, it might be a great candidate to start testing with. The change's name is BACKGROUND_RATIONALE_CHANGE_ID and the change's ID is 147316723. You'll use this information to enable this change before you test your app against it.
After deciding which change you want to test against, you can toggle that change on or off using the developer options. To get to the developer options, open your device's Settings app and navigate to System > Advanced > Developer options > App Compatibility Changes.
Toggleable platform changes in the developer options with the background location access change enabled
In this case, the BACKGROUND_RATIONALE_CHANGE_ID is the only change that is enabled to minimize scope of possible causes for any issues that your app might encounter.
You can also use logcat or ADB to identify which changes are enabled and use ADB to toggle changes on or off. Note that you can only toggle changes when using a debuggable app.
After enabling a change, you can test and debug your app using your typical testing workflows. If you encounter issues, check your logs to help determine the cause of the problem. If it's not clear whether the problem is caused by the platform change that's enabled, try disabling that change and then retest that area of your app.
Check out this week's video on testing platform changes in Android 11 to see another example and read the documentation on developer.android.com.
In addition to manual testing on the new platform, we’ve also made it easier to use Android Studio to run automated tests on the latest OS.
Starting in Android Studio 4.2, instrumentation tests can now be run across multiple physical or virtual devices in parallel. When running tests, there’s now the option to select Multiple Devices in the target device dropdown menu.
This feature is designed to help you catch issues as early as possible in your development cycle and allow you to compare differences between different builds of Android. The results of these tests can be investigated using a new Test Matrix under View > Tool Windows > Run.
The new Test Matrix lets you filter your test results by status, device, and API level.
Check out this week's video on testing app compatibility with Android Studio and read the documentation on developer.android.com.
We encourage you to try out these new tools and send us feedback about how they're working for you. We hope these tools help make it easier for you to test your app for Android 11.
Also, the Android engineering team will host a Reddit AMA on r/androiddev thursday, July 9 at 12:00PM PST, to answer your technical questions about Android 11. See this post for details and to submit your questions.
Android Developers
Google Play
