The Android Version Ratchet

Stack Overflow user kencorbin raised some interesting concerns about the Play Store’s upcoming minimum-required targetSdkVersion and its impact on users of older devices. If your minSdkVersion is below 11, you will need to consider these concerns in the next several months. If your minSdkVersion is below 21, my guess is that you will need to consider these concerns in the next couple of years.

In mid-December, Google announced that new and updated apps distributed on the Play Store will need a targetSdkVersion of 26 or higher. This starts in August 2018 for new apps and November 2018 for updated apps. This is a continuous change: in 2019, the targetSdkVersion requirement will climb to whatever Android P winds up being. And so on.

Starting with v26.0.0, the support libraries minSdkVersion is 14. And that’s where the problems start for developers that support legacy devices:

• If you try shipping with a targetSdkVersion below 26, eventually you will be unable to update the app on the Play Store

• If you raise your targetSdkVersion to 26 or higher, Android Studio will complain if your support library major version does not match your targetSdkVersion

• If you raise the support library major version to match the targetSdkVersion, the support libraries’ minSdkVersion of 14 kicks in, and the build tools will not build your app unless you reconcile your lower minSdkVersion with the minSdkVersion of the support libraries

In effect, the interlocking nature of the support libraries’ minSdkVersion and the Play Store’s targetSdkVersion enforce a ratchet to coerce developers to abandon legacy devices. Today, those legacy devices are those running Android 3.2 or lower, which today mostly are Android 2.3 devices. However, I would expect that Google will raise the support libraries’ minSdkVersion in future years, with the next likely level being 21. I would expect that to happen by 2021, perhaps sooner.

I can understand Google’s desire to set up this ratchet. Partially, as their blog post indicates, it is for security reasons. Plus, accelerating the demise of apps supporting legacy devices will serve as a prod to get users of those devices to purchase replacement devices, which in turn boosts overall security. The fact that users have to purchase new devices is a boon to Android device manufacturers.

And yet, not all developers will be happy with this turn of events.

Besides dropping legacy devices, as Google wants, your options include:

• Use manifest merger and related techniques to continue to use newer support library versions despite your low minSdkVersion. This is fairly risky, in that Google is starting to remove code from the support libraries that is no longer needed for those older devices. Be sure to test very thoroughly.

• Use Gradle’s //noinspection GradleCompatible Lint suppression comment to be able to build your app with a higher targetSdkVersion than the support libraries’ major version, so you can continue using v25.3.1 of the support libraries with a targetSdkVersion of 26 to satisfy the Play Store. This should be safer than the previous option but is not without risk, and that risk increases as the gap increases between the support libraries’ minSdkVersion and your Play Store-satisfying targetSdkVersion. So, using this approach for 2018 might hold up, but come late 2019, with a targetSdkVersion of 28(?), the risk might be too great.

• Switch to a different distribution channel for legacy device users, so you can continue updating your app for them with the older support libraries and a lower targetSdkVersion. This may not be practical for you.

• Stop using the support libraries. This really may not be practical for you.

• Find some way to transition users of legacy devices to some other solution (e.g., progressive Web app) before you are forced to stop updating a version of the app that works on their devices.

• Lobby Google to relax their planned Play Store policy, to require a targetSdkVersion of 26+ only for apps with a minSdkVersion of 14+. In other words, weaken the ratchet so that apps specifically supporting legacy devices can continue to be updated using the older support libraries. While you can ask for this, I am skeptical that Google will be a fan of the idea.

• Convince somebody to maintain a fork of the support libraries that remains backwards-compatible to a lower API level, while perhaps cherry-picking changes introduced in newer support libraries. You could then use that fork in lieu of the official support libraries.

Even if your minSdkVersion is already 14 or higher, you need to start thinking about this so that you are not blindsided if Google raises the support libraries’ minSdkVersion again in the coming years. If nothing else, work on establishing communication channels with your users so that you can let them know about these sorts of issues and your planned response to them.