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
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
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
minSdkVersionand your Play Store-satisfying
So, using this approach for 2018 might hold up, but come late 2019, with
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
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
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.
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!