A New Android Version Is Out – Should I Update My App?

The answer is not straightforward, as there are both good reasons to do it, and good reasons to wait. In this article, I will help you make the right decision on when and how to update your application to deal with a new version of Android.

The Reasons to Update Your App

There are two main reasons to update your application:

• to use the new features introduced in the new version or
• to introduce fixes in order to make your app run correctly on the newest version of Android.

Android users tend to care whether applications use the newer features of the OS. New features are perceived as an attempt to innovate and improve the app. It shows that you care about the user experience.

I remember when Android Nougat came out, and I was fascinated with those apps that had already included the App shortcuts. My interpretation of that was that the apps’ creators were really trying to give me the best experience possible.

The other important factor is that we don’t want to lose the market share by making the app work well only on older versions of Android. We don’t want to let users experience inferior quality (e.g. the app slowing down) because of the changes introduced in the newest release. For example, Android Nougat introduced background execution limitations, which can cause our application to crash while running some services or background tasks.It’s very likely that some issues will come up in the newest Android.

So Should You Update the App? And When?

A lot depends on the nature of your application. For some applications, it would not be necessary to update anything, simply because they would not benefit from using the new features in any way. But it’s still important to test your app on the new Android version to make sure it works as it should.

The truth is that it can take a while for the newest Android version to become available on devices other than Google’s phones (Pixel or Nexus). In other words, you don’t need to panic or hurry, but it might be a good idea to get ready.

Don’t just jump into it, though. Plan out what new features you can add to your app. Be flexible enough with your development schedule to include them. Try to think (even overthink) how you can make them fit in your application to show to the users that you really care about shipping the best app possible.

A great example would be the 5G support introduced in Android 11. Firstly, you should check if your app could use this functionality to boost user experience, for example by showing 4K videos or by enhancing experiences that work best with high speeds and low latency, like the video chat. If those features are important for the app then you should consider upgrading and using new APIs provided by the newest Android.

The migration of your app to a current version should happen in two phases:

• ensure the compatibility with the new version;
• update your target version and use brand-new features.

Ensuring the Compatibility with the New Version

The objective is to make sure that the app works as it should on the new Android release. You don’t need to use the new API or change the targetSdkVersion (which informs the system that your app is working well against it), but there are still several steps you need to take:

1. First, you need a device or an emulator running the newest Android.
2. Review the system behaviour changes to detect where your app may be affected and install the app in your emulator or device to run tests.
3. Focus on system behaviour changes. Check the changelog and make sure that the changes in the system are not affecting your app’s performance or functioning.
4. Make changes in the code to support the behaviour changes or resolve issues.
5. Finally, publish the new APK and enjoy the first half of a job well done!

Updating Your Target Version and Using The Newest Features

This is the exciting part: enable full support for the new version by updating the targetSdkVersion and adding new features introduced in Android. To do this, you need to:

1. Update Android Studio to the current version (if you haven’t yet) and update the targetSdkVersion and other build configs.
2. Get a device or emulator running the new Android.
3. Review the system behaviour changes to detect where you can use the new features.
4. Make code or architectural changes (as needed) to support the new features and capabilities.
5. Test on devices or emulators with the new Android version, and older android versions as well. You want your app to work well for as many users as possible.
6. Publish the new APK.
7. Enjoy the full experience of a job well done!

You can find some extra information on how to deal with this process of migrating to Android 11 here.

Once you’ve applied the changes, test your future release on older versions of Android to make double sure that it runs correctly. You should make sure your code handles deprecated API methods.

I recommend you check the changelog to be sure that your application is not using any deprecated methods. You can also check with lint, a tool for static analysis (it will scan the code, looking for existing or potential problems), to be sure that the new version is fully supported.

Final Thoughts

As a rule of thumb, always start testing and working on the updates with the Beta versions of the new Android releases, some months before the effective release. It’s important to check changelogs to search for potential new features or improvements for the application, but if it’s already too late, use the four or six months since the version is released until it is adopted.

Don’t be afraid of updating your application to a new SDK. In general, nothing should change dramatically, and old versions are still supported. But take the time to check exactly what changes you should make and to test the app’s new version on the latest Android.

Don’t rush. Usually, when a new version is released, there is some time until the market starts using the new version.

Also, if you'd like to find out more about developing successful Android projects, check out this article.