The Android 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 for new apps and November 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 on the Play Store

  • If you raise your targetSdkVersion to 26 or higher, Android Studio will
    complain if your support library 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 v2.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 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.

Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!


Source link


Please enter your comment!
Please enter your name here