6 Tips to Migrate Enterprise Apps to Android 11
With Google gearing towards the stable and final release of Android 11 by the end of the third quarter of 2020, I’m sure a lot of Android developers are looking to adapt their applications to support the newest version of Android.
Android R, more commonly known as Android 11, comes packed with an array of new and exciting features including 5G support, one-time permissions, scoped storage and a lot more.
I’ve discovered a few critical points for other Android Devs to keep in mind while transitioning enterprise app code for compatibility with Android 11 ‘R.’
1. Read the Android 11 Documentation
Every app uses various aspects of the Android SDK to a varying degree. The best place to start understanding the extent of the impact of Android 11 on your enterprise app is to read the official documentation preview. Since 11 ‘R’ is in Beta, take note that the documentation could change, but it’s still a solid rule book for a smooth migration.
Historically, I’ve had limited exposure to the main app codebase. But, I found that reading and re-reading Android 11 changes made it much easier to identify the root cause when I stumbled on an issue that didn’t work quite as expected.
Direct exposure to the developer docs made the code migration process faster. It created an experience that was immensely less frustrating. Plus, it gave me insight into the code migration that would have otherwise been really difficult to decipher.
2. Test for Compatibility
Performing a thorough regression and sanity test of an application after any major change is a clear necessity. But, it’s especially important in this case. The need for compatibility testing is very clearly pointed out in Google’s official documentation. I found regression and sanity tests yielded a deeper understanding of both app and codebase.
Also, I learned that making a spreadsheet that listed virtually every key and minor app functionality lead to a much more organized, well-planned testing experience. If possible, I’d recommend having your functionality list vetted by a team member with extensive experience testing your Android enterprise app.
Related: Here’s how to test apps on Esper’s custom Android device emulators.
3. Refer to the Source Code
It can be frustrating to look for the root cause of something that doesn’t behave quite as expected, especially if the issue isn’t clearly explained in the developer docs. I found combing through the Android 11 source code was a direct and practical approach that saved a lot of time. Plus, it gave me a good excuse to look under the hood.
Understanding the changes to the source code between Android 11 and prior versions helps devise a clean migration. Understanding the source code can help Android Devs create a maintainable update instead of just a temporary patch.
4. Upgrade Gradle to 6.1.1
With changes like package visibility and supporting the newer default settings for Android 11, a Gradle upgrade is inevitable. An Android R migration project should involve a step to update the build version of Gradle 4.0.1 in the project level build of your app.
If Android 11 will bring an update to your CI/CD environment, it’s important to know the latest build version is based on Gradle v6.1.1. Also, the output.json created with the .apk file is renamed to output-meta.json in this Gradle release.
5. Understand Package Visibility
A new Android manifest tag is being added to the <queries> tag. This means that all packages are no longer publicly visible in Android R. The Android manifest tag defines the other apps that your app is going to access to query or interact with – including binding services (AIDL, messenger, etc.), explicitly launching the activity of the other app and many other scenarios.
Android 11 also includes a new permission, QUERY_ALL_PACKAGES, for apps that have required access to all installed applications on the phone. This is not an inherently dangerous permission and it’s not required for users to grant permission.
Ultimately, the best approach to handle package visibility for your particular single-purpose use case will vary. Here is the link to the official docs to understand impact.
6. Non-SDK Restrictions
Android has been cracking down on the use of non-SDK API’s and interfaces for some time now to ensure the safe and correct use of its APIs. They’ve taken this a step further in the Android R release.
All new API’s, added in Android 11, denoted with @TestApi in the AOSP are now blocklisted by default. Also, a large chunk of the previously greylisted APIs have been moved to the blocklist. Here’s an exhaustive list of current grey and blocklisted APIs.
Careful testing is the best way to identify APIs that will now cause issues in Android 11. In many cases, developers could discover that it’s hard to find a publicly available, equivalent API and that it’s now necessary to make appropriate changes to the flow.
Are Your Enterprise Apps Ready for the Public Release of R?
These were a few key takeaways from my recent work with app migration to the latest Android version. Android 11 is an exciting release that’s packed with new features and improvements.
Starting migration now will give Android DevOps teams ample time to explore, understand and optimize apps before the stable release launches. The best type of migration experience to Android 11 is one that’s smooth and seamless.
Android 11 has some pretty interesting implications for single-purpose Android fleets. Notably, new enhanced work profiles will replace Google work profiles for fully-managed, GMS-certified Android. This change will have a particularly big impact on deployment scenarios where devices are shared among multiple internal users or instances where some personal use is permitted.
In the days ahead, we’ll share some best practices for securely and seamlessly migrating Android 8-10 devices with work profiles to Android 11.
Esper has been providing Android 11 Beta support to customers to facilitate an easier transition of devices, apps, configurations, and content across OS versions. Click here to request a demo.