Google Play services discontinuing updates for Jelly Bean (API levels 16, 17 & 18)

Posted by Vikas Kansal, Product Supervisor, Google Play companies

The Android Jelly Bean (JB) platform was first launched 9 years in the past and as of July 2021, the lively machine rely is under 1%. Since then Android has launched a variety of enhancements and options which aren’t all backported to Jelly Bean. This ends in elevated developer and QA time spent on new options that require particular dealing with. Consequently, we’re deprecating assist for JB in future releases of Google Play companies. For units operating JB, Google will now not replace the Play Providers APK past model 21.30.99, scheduled for the tip of August 2021.

What does this imply as an Utility developer:

The Google Play companies SDKs comprise the interfaces to the performance offered by the Google Play companies APK, which runs as background companies. The performance required by the present, launched SDK variations is already current on JB units with Google Play companies and can proceed to work with out change.

Every SDK may be independently launched and should replace its personal minSdkVersion. Particular person libraries should not required to alter primarily based on this deprecation. Newer SDK parts could proceed to assist API ranges 16 via 18 however many will replace to require the upper API ranges. For functions that assist API ranges 19 or larger, you’ll not have to make any modifications to your construct. For functions that assist API ranges 16 via 18, it’s possible you’ll proceed to construct and publish your app to units operating JB, however it’s possible you’ll encounter construct errors when updating to newer SDK variations. The error will appear to be this:

Error:Execution failed for job ':app:processDebugManifest'.
> Manifest merger failed : uses-sdk:minSdkVersion 16 can't be smaller than model 19 declared in library [com.google.android.gms:play-services-FOO:19.X.YY]
        Suggestion: use instruments:overrideLibrary="com.google.android.gms:play_services" to power utilization

Sadly, the said suggestion won’t allow you to present app updates to units operating JB or older. With a view to use the newer SDK, you have to to make use of one of many following choices:

1. Use API degree 19 because the minimal supported API degree.

That is the beneficial plan of action. To discontinue assist for API ranges that may now not obtain Google Play companies updates, merely enhance the minSdkVersion worth in your app’s construct.gradle to at the very least 19. In the event you replace your app on this manner and publish it to the Play Retailer, customers of units with lower than that degree of assist won’t be able to see or obtain the replace. Nonetheless, they are going to nonetheless have the ability to obtain and use essentially the most lately printed model of the app that does goal their machine.

A really small proportion of all Android units are utilizing API ranges lower than 19. We imagine that many of those previous units will not be actively getting used. In case your app nonetheless has a major variety of customers on older units, you need to use a number of APK assist in Google Play to ship an APK that makes use of Google Play companies 21.30.99. That is described under.

2. Construct a number of APKs to assist units with an API degree lower than 19.

Together with some configuration and code administration, you’ll be able to construct a number of APKs that assist completely different minimal API ranges, with completely different variations of Google Play companies. You’ll be able to accomplish this with construct variants in Gradle. First, outline construct flavors for legacy and newer variations of your app. For instance, in your construct.gradle, outline two completely different product flavors, with two completely different compile dependencies for the parts of Play Providers you are utilizing

productFlavors {
    legacy {
        minSdkVersion 16
        versionCode 101  // Min API degree 16, v01
    }
    present {
        minSdkVersion 19
        versionCode 1901  // Min API degree 19, v01
    }
}

dependencies {
    legacyCompile 'com.google.android.gms:play-services:16.0.0'
    currentCompile 'com.google.android.gms:play-services:17.0.0'
}

Within the above scenario, there are two product flavors being constructed towards two completely different variations of play-services-FOO. This can work wonderful if solely APIs are known as which can be accessible within the 16.0.0 library. If it’s essential name newer APIs made accessible with 17.0.0, you’ll have to create your personal compatibility library for the newer API calls in order that they’re solely constructed into the model of the appliance that may use them:

1. Declare a Java interface that exposes the higher-level performance you wish to carry out that’s solely accessible in present variations of Play companies.
2. Construct two Android libraries that implement that interface. The “present” implementation ought to name the newer APIs as desired. The “legacy” implementation ought to no-op or in any other case act as desired with older variations of Play companies. The interface needs to be added to each libraries.
3. Conditionally compile every library into the app utilizing “legacyCompile” and “currentCompile” dependencies as illustrated for play-services-FOO above.
4. Within the app’s code, name via to the compatibility library every time newer Play APIs are required.

After constructing a launch APK for every taste, you then publish them each to the Play Retailer, and the machine will replace with essentially the most applicable model for that machine. Learn extra about a number of APK assist within the Play Retailer.