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
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
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
targetSdkVersionbelow 26, eventually you will be unable to update the app on the Play Store
If you raise your
targetSdkVersionto 26 or higher, Android Studio will complain if your support library major version does not match your
If you raise the support library major version to match the
targetSdkVersion, the support libraries’
minSdkVersionof 14 kicks in, and the build tools will not build your app unless you reconcile your lower
minSdkVersionof the support libraries
In effect, the interlocking nature of the support libraries’
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’
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.
//noinspection GradleCompatibleLint suppression comment to be able to build your app with a higher
targetSdkVersionthan the support libraries’ major version, so you can continue using v25.3.1 of the support libraries with a
targetSdkVersionof 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’
minSdkVersionand your Play Store-satisfying
targetSdkVersion. So, using this approach for 2018 might hold up, but come late 2019, with a
targetSdkVersionof 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
targetSdkVersionof 26+ only for apps with a
minSdkVersionof 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.