How We Migrate Our Big Project to AndroidX in Tokopedia

Rifqi M Fahmi
Nov 27, 2019 · 5 min read

In May 2018, Google announced it’s brand new artifacts AndroidX, initiating the new era for the Android support library. One of the reasons Google decides to create AndroidX is because many developers are confused with the artifact naming, such as “v7” when the minimum supported SDK is 14! Now, Google wants to combine it, and all of the different versions of support libraries are packaged under one consistent “AndroidX” namespace. The development of new features will no longer be developed in support libraries. Instead, it will be developed in AndroidX.

By the time AndroidX was ready for production applications, Google is slowly enforcing developers to use it. One of the examples is in Android Studio 3.5. You can’t create a new Android module if you are still using the support libraries.

New Module Android Studio 3.5

We realize that anytime soon, we need to migrate our codebases to AndroidX. Fortunately, Google provides a tool in Android Studio to migrate a project that uses support libraries to use AndroidX with a single click of a button which you can see in Refactor -> Migrate to AndroidX…. And there is also Jetifier, a tool to migrate support-library-dependent libraries to rely on the equivalent AndroidX packages. Unfortunately, it didn’t work well for us.

The Challange

In Tokopedia, we have a huge mono repo with over 150++ modules and 20k++ files. When we try using the provided tool above, we are faced with a ridiculously long indeterminate process. Almost 6+ hours, the migrating process was still not finished.

Indeterminate process

We decided to terminate the process and find another way to migrate our project.

The Solution

We realized that the migration process is just as simple as replacing the support packages and namespace to AndroidX equivalent. We came across this page where Google provides the artifact and class mappings files that we can download in CSV format. We then decided to create a script to migrate our project.

The Migration Process

With just 400 lines of python codes and a simple find and replace concept, we able to create a script that converts all support artifacts and namespaces to AndroidX. It only took about ~5–10 minutes to migrate the project.

Migration process

Can it be Compiled? Of Course Not!

But the challenge did not end yet. We have to make sure that the compiler can compile the code and everything is working as it’s supposed to be. And our prediction was right. The code can’t be compiled. There are dependencies conflict on several libraries that cause the Jetifier can’t migrate when compiling the code. Some of the libraries are Airbnb DeepLinkDispatch and Glide.

Error on Airbnb DeepLinkDispatch
Error on Glide

We found that this problem occurs when the library still dependent on some of the v4 support library and cause the Jetfier can’t migrate the artifact to the AndroidX artifact. We decided to upgrade the library’s versions to the version that supports AndroidX. The DeepLinkDispatch library is not compatible with AndroidX until version4.0.0 While the Glide library is until version 4.8.0

While the other conflicting libraries don’t need to change its implementation when upgrading its version, it’s not the case for Glide though. The Glide version we were using was3.7.0 while the latest version we wanted to use is 4.9.0. Besides upgrading its version, it also requires the Glide implementation migration itself, the Glide V3 and V4 have significant differences and major changes. We were not sure yet whether the Glide V4 will make the compile process success or not.

Before we migrate the Glide V3 to V4 equivalent implementation, we need to make sure that it’s the only remaining problem we are facing to compile our code successfully. So we commented on all our code that implementing or referencing Glide and upgrade its version to V4. It’s like we skip the current problem to see the final result first. Surprisingly, we successfully compiled our code with the AndroidX artifacts, and we began the implementation migration of Glide V3 to V4.

Testing Phase

Now comes the testing phase, after we able to generate and compile the app bundle successfully, then we move to the testing phase. Currently, our build was a success. The next step is to ensure there is no runtime error or crash, and all features behave as it’s expected to be. After a while, we found a crash, a strange crash. Why strange? Because it’s only happened in Android KitKat and below.

This error comes from the old deprecated library we were using It happened when the view activity using the library component. To fix this error, we decided to remove this library and use our own implementation.


AndroidX is the new era of the support libraries. To keep up to date with the latest Android technology, we need to migrate our project to AndroidX. We create a python script to do the conversion. After the migration, the compiler can’t compile the code because of several dependencies did not compatible with AndroidX. To fix the errors, we decided to upgrade the conflicted libraries version to the one that is compatible with AndroidX. The significant changes were with the Glide library implementation, which we also need to do the implementation migration because the V3 and V4 have major differences.

Rifqi M Fahmi

Written by

Android Wizard

Tokopedia Engineering

Story from people who build Tokopedia

More From Medium

More from Tokopedia Engineering

More from Tokopedia Engineering

More from Tokopedia Engineering

Deciphering the Art of Estimation

More from Tokopedia Engineering

More from Tokopedia Engineering

Backpressure in Reactive Streams

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade