The Journey To Android Monorepo: The History Of Uber Engineering’s Android Codebase Organization

During our inaugural Uber Technology Day, software engineer Aimee Lucido delivered a presentation on the history of Uber Engineering’s Android codebase. In this article, she expands on the reasons behind Uber’s decision to build a monorepo to support the growth of our Android development.

Today is the day you are going to build a brand new Android app—and good for you, getting started is always the hardest part. What is the first thing you do?

If you are like me, you will create a new project in Android Studio. You make a main activity, hook up Gradle, and maybe even create a git repository so that your friends can collaborate with you on the app. Congratulations! Your code organization now resembles the first version of the Uber Android rider app.

When we launched our Android rider app in 2010, we were a small company. Uber Engineering was under a dozen people. We had one contractor working on the Android platform, and—if you can believe it—we did not even have an Android driver app. So, our single Android engineer wrote the first version of the rider app in a single repository: one big box of code.

Creating a new app using a single repository had some benefits early on:

For several years, the state of Android at Uber was small scale. By 2013, we had hired our first full-time Android engineer, and over this period our engineering team had more than doubled. Only then did we start building an Android driver app.

Building the driver app gave us the opportunity to improve our codebase organization. The rider app still existed in a single codebase, but since we now had the resources and tooling to extract reusable components, we did just that. The core partner code existed in its own separate repository, but we also built out a library full of reusable components for the two apps.

This general structure served us well for awhile, but in 2014, our subsequent growth called for a different solution. Uber had over a hundred engineers. The Android engineering team had grown in size from one to eight engineers. As our number of engineers was growing, so too did our codebase.

We took a look at the direction that we were heading and we realized that if we did not change, we were going to encounter the following issues:

So during the 2013-2014 time period, we made a series of changes to transition to a multirepo codebase in order to preempt these problems. In 2013 we moved our rider app from Eclipse with Ant to IntelliJ with Maven, allowing us to pull artifacts from a server and breaking our library codebase into 20+ smaller decoupled repos. (For example, networking was moved to its own repository, later to be pulled into the consumer apps via a Maven repository at compile time.) Simultaneously, we transitioned our build scripts to Gradle, marking our first foray into a multirepo world.

Our Uber multirepo codebase consisted of several little codebases each representing a single, discrete idea stored as artifacts that are pulled in at compile time by the rider and driver apps. Each repository is like a smaller box of code, with its own IDE project, git repository, and build script. By moving to multirepo, we ensured a solid, future-proof architecture, circumventing problems like long build times, feature coupling, and a broken master.

So the question now becomes: why did we not start with a multirepo from the beginning? In one word: overhead. Breaking features out in their own repositories requires a significant amount of time and expertise to set up. It requires in-depth knowledge touching multiple areas such as Maven, Gradle, VPNs, and artifact management. This knowledge down payment only becomes worthwhile as the scale of the company increases.

For nearly three years we operated, scaled, and thrived with a multirepo organization. But by 2016, our multirepo setup began to reach its limits, and our developers butted up against the following new issues:

So what did we do?

The answer to our problems: investing in a monorepo, a single repository containing multiple, independent projects. A monorepo exists in one codebase, just like our initial rider app. But unlike our initial rider app, this new instantiation of all code in one box contained multiple logical components that operate independently. Thus, we can now invest the time and resources into tooling and architecture necessary to fix many drawbacks of a large, single repo:

This may seem like a lot of overhead, and it is. There is no out of the box way to create a monorepo, because there are only a handful of companies right now that have the scale requiring it. But for every pain point that we predicted back in 2013, we now have the time, expertise, and resources to build tooling to prevent them from hampering our productivity.

As you can see, it took Uber many years to get to this latest stage of development. When we were a small, scrappy team of just a few engineers, we did not have the time or resources to create Submit Queue or set up Buck. But our early foresight encouraged architectural decisions that have allowed us to scale as quickly as we have. Now that we have scaled even further, we can invest in a development down payment to ensure that the future service growth is seamless and efficient.

Developer productivity is hard but important work, and with every incremental improvement, we are not just bettering Uber but the Android community at large. If growing Uber’s Android monorepo sounds interesting to you, considering joining our mobile engineering team—we are hiring!

Software engineers JJ Ford and Gautam Korlam also contributed to this article.

Photo Header Credit: “Resting reedbucks in late afternoon” by Conor Myhrvold, South Luangwa National Park, Zambia.