Android’s Google play:core library Breakup

A few weeks ago, my team and I encountered an unexpected error when we attempted to integrate one of the new core Google Play Store library interfaces into our app.

I was mesmerized by this error, as it didn’t make sense why in the world would we have two copies of the same classes in our application, after simply adding a new dependency into the app-level build.gradle file.

After a few minutes of research and StackOverflow to no avail, we ended up looking into the library’s Release Notes where we were able to better understand what was going on.

As it turns out and is very nicely explained by the Android developers website we ended up looking at, the Google Play Store’s core monolithic library was broken up into multiple targeted libraries. These new broken-down libraries are meant to individually focus on the different features that the core library already had, while. The core features we’re talking about being, Task objects from com.google.android.play.core.tasks.*, managing delivery asset packets, delivery of feature modules, downloading additional language resources, triggering in-app updates, as well as requesting in-app reviews.

In this article, I will go over a quick and simple migration guide on how to properly move past the Google Play Store’s core library, and instead integrate the new separate feature libraries as needed.

Setting Up Basics

First thing’s first, since the com.google.android.play:core is no longer receiving support from past version 1.10.3, deleting this dependency from build.gradle, and all associated imports would be the first step into a successful migration.

As soon as that’s done, you may find compilation to start failing for your project, which brings us to the next few but optional steps, which may or may not apply to individual projects.

Update All Task Objects

If your application utilizes any imports for the library com.google.android.play.core.tasks.*, then replace all of these with the package com.google.android.gms.tasks.*. If this is the case for your project, all class names should stay the same.

Update Asset Delivery feature

If your application uses the dynamic asset delivery feature from the Google Play Store, a pattern mainly used by games to dynamically deliver extra artifacts to the player outside of the initial app bundle download, you’ll have to bring in the new android.play:asset-delivery dependency into your build.gradle.

Update Feature Delivery feature

If your application uses the feature delivery feature from Google Play Store, a pattern that allows for your app bundle to be delivered conditionally or downloaded on demand, you’ll have to integrate the new android.play:feature-delivery dependency into your build.gradle.

Update In-App Review feature

If your application uses the in-app review feature, a library that gives the ability to request a review from the User without leaving the application, you’ll have to integrate the new android.play:review dependency into your build.gradle.

Update In-App Update feature

If your application uses the in-app update feature, a library that gives the ability not only to check for updates, but also to enforce application updates from the User while inside the app, you’ll have to integrate the new android.play:app-update dependency into your build.gradle.

BONUS: The Play Core Common Library

Additionally, there’s a new android.play:common library that simply contains two classes — IntentSenderForResultStarter & LocalTestingException — that also comes from the outdated monolithic library. If your application utilizes either of these classes, an extra dependency will be needed in order to migrate them into your application

And that’s it! I hope that this quick guide can help other developers having trouble with the recent Play Store core library migration, and make the break-up easier for everybody going through it as we did.