Doing These Things Can Reduce Your Anxiety in Moving to Android 14
They may even prompt you to get excited about migrating applications to a new operating system (OS) rather than dreading or delaying it.
It’s always a fear of the unknown that seems to sideline us, right?
We don’t know what to expect, so we start devising all these worst-case scenarios in our head. By the time our minds are done mapping out all these scenarios, we’ve come to believe that whatever we were thinking about doing “isn’t worth the risk.”
In business, it’s this fear that stifles innovation, progress, improvement, digital transformation…whatever you want to call it. Not budget. Fear of the unknown.
There’s a common perception that any sort of tech project is going to be this huge lift that’s going to take a massive team, months of time, and loads of money – even if it’s just a routine transition to the next Android operating system (OS), which is something we’ve all done several times now.
So, I thought we could face that fear head on together and, perhaps, squash it once and for all.
It’s about time to move your applications to Android 14, and I’m not a “ready or not” kind of guy. I want you to be 100% ready, both technologically and mentally. That’s why I want you to know:
1. what needs to happen to get your devices and applications up and running on Android 14.
2. the best way for the migration to happen.
3. the real reasons why this migration needs to happen now, even if you’d prefer to wait as long as possible.
Once we talk about these things, I think we can flip the script I so often hear in the business and IT community about each required “Android migration”. It will no longer feel risky or burdensome; it will only feel risky not to do it right now because the update will be so rewarding.
First things first: Let’s talk about why it’s important to move your mobile workers (and the applications they use) to the Android 14 OS.
What Android 14 is Going to Do for You/Your Operation
As with all new Android versions, moving to Android 14 ensures…
- you have all the latest security patches and bug fixes. Waiting until you have an issue is introducing unnecessary risk into your operation.
- you have access to the latest third-party applications and libraries. Many third parties remove support for older OS versions over time.
- you can continue to receive application updates via the Google Play Store. For security reasons, Google sets a minimum API level (OS version) for applications that can be distributed thru the Play Store.
- you’re able to take advantage of new features only available on the Android 14 OS. For example, the Credential Manager will allow you to integrate a standard approach to sign into your application both with passwords and via passkeys if you don’t want to use a password. With Android 14, you will also be able to preserve privacy and reduce the potential loss of sensitive data by controlling when a user can take device screenshots. For example, a healthcare electronic medical record (EMR) application might not allow screenshots of patient personal information. Something else you can do with Android 14 is make updates to the “per application” language preferences originally introduced in Android 13. This allows Android devices with the same system language to be more easily shared across multilingual users.
Of course, there are many other features that you may find extremely beneficial that will only be available with Android 14, but I didn’t want to get into them all here. So, checkout the full list in the links I’ve dropped in at the end of this post. Before you do, let’s talk about why you’re really here: understanding how to quell the anxiety building in anticipation of yet another move to a new OS.
What You Will Need to Do to Get Your Team Up and Running on Android 14
I believe knowledge quells fear. Getting the facts is the only way you will know what you’re really up against (or how little there really is to fear). So…
Step one: Learn about all the changes that have been made in the new OS version you are targeting – whether it’s 14 or some other version. (Again, the full list of Android 14 changes can be found in the links at the end of this post.)
Step two: Confirm how they may affect your application*. The good news is that it’s very likely there will be no changes required to your application, at least if you’re targeting Android 14 - or only minor changes like adjusting for new permissions, declaring the appropriate foreground service type, and properly handling installation of unknown apps.
*As with prior OS upgrades, Zebra has put together a detailed technical blog post with the areas most likely to impact applications on Zebra devices. This is designed to complement the complete Google documentation referenced below. We have been developing this series of Developer Blog posts since the upgrade to Android Marshmallow/Android 6, and it is one of the most popular blog series for our technical audiences.
Step three: Commit to upgrading to new OS versions and have a plan to periodically update. Given that Android releases a major OS update every year, this is a good target as the changes are cumulative. Skipping updates and jumping several versions at once increases the complexity for you, particularly for testing. I would highly recommend taking an agile approach and doing one version at a time as they are released rather than a “big bang” approach of trying to upgrade multiple OS versions in a single leap. Many application developers use this yearly OS update as an opportunity to add additional new features, reduce technical debt, or refactor sections.
Just be careful…
While it is tempting to have multiple application versions, one for each OS variant, avoid that like the plague. Coordinating fixes and features and supporting multiple versions is highly complex and grows exponentially with each new version.
Fortunately, with compatibility libraries (Android calls them JetPack libraries) and build options for target API levels, it is not only possible but the norm to have a single application version support multiple Android OS versions.
Google has also added a powerful developer feature called the Compatibility Framework. This tool allows developers to toggle individual software development kit (SDK) changes so they can isolate areas that might impact their application. The really powerful part is the changes can be enabled and tested without actually rebuilding to the new SDK version. This allows developers a quick way to assess the impact to their application(s) using their current build on the prior OS version. While some changes are not available through this method, it provides a great head start.
Again, you can find more information in the Zebra and Google technical blogs below.
What Challenges You Might Run into Along the Way (But You Can Avoid if You Expect Them)
By far the biggest concern I hear about OS upgrades is, “How do I test it? It requires months to fully test and even then I am not confident in the quality.”
While there unfortunately is no magic bullet to that question, we’ve noted some best practices based on our internally developed software and what we have seen work with independent software vendors (ISVs) and customers.
My opinion: The most important aspect of a test strategy is to invest in test automation.
This saves you the time and resources required to execute test and also significantly improves code quality as the expected results need to be well defined, and tests can be run more frequently. Having a test automation strategy for your testing can be leveraged when a new OS is available.
I have seen the opposite way taken too often: People get a new OS version, load their applications and “play” with it to see what happens. Please don’t do that (anymore.)
While the technical details are beyond the scope of this blog post, Android Studio and several third parties have some excellent testing tools; a good starting point is here. Test automation tools will be one of the early beneficiaries of the explosion of powerful large language models (LLMs) and generative AI (GenAI) tools, so now is a good time to invest if you have not already done so.
Another piece of advice: Have a well-defined beta test program. Start with a trusted set of users with diverse use cases, roles, locations, etc. so you get good representative coverage. Once you are ready to deploy, logically stage the rollout by location, role or other logical grouping rather than all at once.
/content/zebra1/global/master/In my experience, the best way to make the migration to a new Android OS “just another day at the office” is to ask these questions upfront – and find someone you trust to answer them:
- Do I know what changes to expect in this new Android OS?
- Do I have a test plan and automation strategy?
- How will I beta test and distribute the updates?
- What is the best time frame to distribute the update to minimize disruption?
If you understand these things, it’s going to be hard to get caught off-guard as you move through the migration. If there aren’t any surprises (because you’ve planned out the project, brought in the right resources, and executed perfectly), then you’ll never see an Android OS migration as painful again. In fact, the next time you have to move to a new OS, you’ll probably jump right in because you’ll remember, “It was pretty easy last time. We finally got the process down pat, we didn’t have any surprises, and we got immediate benefits from it once we went live.”
Of course, all our newer devices based on the Qualcomm 6490, 5430, 6375, 4490 CPU architectures will have upgrades to Android 14. Plus, all Zebra mobile devices based on the Qualcomm SD660 chip are still upgradable to A14, even though some are six years old! We made a huge effort to protect your investment in our hardware.
So, follow the steps I noted above, heed my cautionary advice about what not to do, and suddenly the fear of the unknown – or the fear of pain based on past trauma with tech projects – will disappear forever. You’ll wonder why you ever dreaded or avoided an Android OS update before. You might even start to see this as one of the easiest things you have to do at work. It can happen. 😉
P.S. If you’re a developer that’s being tasked with making this migration happen or you know one, you’ll want to go here for all the gory technical details on how to get it done. And remember let’s keep the scary things for the upcoming Halloween holiday, not OS upgrades.
