Posted by Diana Wong, Product Manager, Android
This blog post is part of a weekly series for #11WeeksOfAndroid. For each #11WeeksOfAndroid, we’re diving into a key area so you don’t miss anything. This week, we’re spotlighting Android 11 compatibility; here’s a look at what you should know.
Android 11 compatibility week
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.
Making app compatibility easier in Android 11
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.
- Minimizing the impact of behavior changes – we’re making a conscious effort to minimize platform changes that could affect apps by making them opt-in, wherever possible, until you set targetSdkVersion to Android 11 in your app. If you are distributing through Google Play, you’ll have more than a year to opt-in to these changes.
- Easier testing and debugging – To help you test for compatibility, we’ve made many of the breaking changes toggleable – meaning that you can force-enable or disable the changes individually from Developer options or adb. With this change, there’s no longer a need to change targetSdkVersion or recompile your app for basic testing. We’ve also made it easier to use Android Studio to run automated tests.
- Restrictions on non-SDK interfaces – as part of our ongoing effort to gradually move developers away from non-SDK APIs, we’ve updated the lists of restricted non-SDK interfaces, and as always your feedback and requests for public API equivalents are welcome.
- Dynamic resource loader – As part of their migration away from non-SDK interfaces, developers asked us for a public API to load resources and assets dynamically at runtime. We’ve now added a Resource Loader framework in Android 11, and thank you to the developers who gave us this input!
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 on 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:
- How do you determine which areas of your app might be affected?
- Should you test by changing the
targetSDKVersion,and what’s the easiest way to do so?
- Once you begin testing, how do you isolate the issues that are causing problems?
- As you develop and test against the latest version of Android, how do you verify that your app continues to provide a seamless experience across other devices with different form factors and lower API levels?
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.
New tools for testing platform changes
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.
What is the 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.
Choosing a change to test against
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.
Isolate the change
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.
Test and debug your 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.
New tools in Android Studio for testing app compatibility
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.
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.