In May 2018, Google announced Android Jetpack / AndroidX — a collection of libraries which is meant to be the successor of the Support Library. Along with the AndroidX components, the tool named Jetifier was released. The goal of the Jetifier is to migrate your application’s dependencies and transitive dependencies to AndroidX preventing clashes between two different, but similar library groups. In other words, after running Jetifier during the build time, your project and your dependencies should be 100% migrated to AndroidX. In most cases, Jetifier is used during Gradle builds, though the standalone version is also available.

Why should I care about Jetifier?

Jetifier is meant to be a temporary tool. If all of your dependencies are migrated to AndroidX, why keep it turned on?

Also, Jetifier operates on all of your libraries, it doesn’t matter if they use Support Library or not. And “jetifying” bigger dependencies can take some time. For the application I’m working on, Gradle profiler showed that JetifyTransforms took a total of 12 seconds to run on my Mac. Digging deeper, running Jetify on org.clojure:clojure took 1.683s, kotlin-reflect: 1.176s, guava: 0,941s and all of them are non-Android libraries. Maybe there could be a way of specifying a list of dependencies to be jetified?

Of course, 12 seconds is not that much, and this was measured on a clean build, with a clean Gradle cache. In most cases, Gradle will use the cached results of transforms. But if you’re running your CI builds in a clean environment (like a Docker container), jetification will be needed each time you run a build.

You can also try to pre-transform .aar packages using a standalone Jetifier command-line tool, but then you have to host somewhere jetified dependencies (private Maven repository?). The process can be more complicated if you need to transform transitive dependencies of your dependencies.

Dropping the Jetifier

If all of your dependencies are already migrated to AndroidX, you can safely turn the Jetifier off. If you’re updating your dependencies regularly, you can also from time to time check if you can drop the Jetifier. But how can one know if there are no more dependencies using Support Library left?

The first answer is to run the dependencies Gradle task (along with the android.enableJetifier flag switched to false) on your application module and examine the output. If some of the listed modules names start with com.android.support or android.arch, this most likely means that you have to keep the Jetifier turned on.

And why “most likely”? Well, if you have two packages with android annotations included, probably nothing wrong will happen. If you have some non-trivial Support Library and AndroidX modules included at the same time, some components, like resources, can clash, and your application won’t compile, or its behavior can be unpredictable. Even if you’re successful, you will end up with some duplicated classes and resources. As a result, your application size will be increased.

But examining the output of the “dependencies” task can be hard, especially if your application has a large number of libraries included. That’s why I’ve prepared a simple Gradle plugin that obtains the dependencies configurations for each of the modules and lists all the packages that take advantage of the Support Library, either directly or via transitive dependencies.

By running the canIDropJetifier task, you can obtain the list of all the dependencies that take advantage of the Support Library. You can set the verbose flag to true to print the tree of transitive dependencies that lead to dependency on Support Library package.

So what were the results of running canIDropJetifier for the application I’m working on?

Play Services and Firebase

There are no AndroidX versions of Play Services and Firebase packages yet. This can be justified by the amount of the code needed to be migrated. But during the analysis of the canIDropJetifier task’s output, I’ve noticed that the play-services-basement package depends on the fat support-v4 module! In August 2016, the v4 Support Library v24.2.0 was split into smaller packages, and the play-services-basement still didn’t take advantage of this. Which means that if you add any of the Play Services/Firebase to the clean Android project, all of the support-v4 classes and resources will be included (unless you use Proguard).

Navigation Architecture Component

The first alpha of the Navigation Architecture Component was announced the same time as Jetpack (Google I/O 2018). There is no AndroidX artifact of this library available yet, and most likely the reason is that Google didn’t want to block people from testing the Navigation component by requiring them to migrate to AndroidX. Navigation component reached a beta status in January 2019, but the AndroidX package will be available when the final 1.0 version is released.

Other libraries

As I’m writing this in February 2019, some of the commonly used libraries do not have their AndroidX versions yet. The list includes dagger-android, Glide and LeakCanary. Some of the libraries are migrated, but no stable version is available yet (like RxBinding, 3.0.0-alpha2 is the newest version supporting Jetpack). Many libraries have already been migrated; the list includes ButterKnife and Airbnb’s libraries: Epoxy and Paris. I guess we can say that the overall process of migrating widely used libraries is in progress.

Summary

I guess it’s safe to say that the Jetifier tool is here to stay with us for at least a couple of months. With the upcoming release of Android Q, which will not have the corresponding Support Library 29.0.0 released, the awareness of a need to migrate to AndroidX should increase. This can result in a way more projects migrated to AndroidX, and hopefully more libraries also. It’s important to update our dependencies frequently and to check if AndroidX artifacts are available. I’m looking forward to the day of dropping Jetifier!