Press Kit
I'm logo
Arnav Gupta | April 24, 2019
How we cut the build time for our Android app by 95%

How much time does it take you to rebuild your Android app every time you make changes?

How much time do you think the Zomato app used to take to build for our engineering team? Here are some reference points for you to be able to take an intelligent guess –

  • 29 submodules
  • 6400 java files, 1300 kotlin files and over 17000 xml files
  • ~1.2M lines of Java

Well, here is the typical build time it used to take –

2 minutes and 18 seconds. Let’s estimate the huge amount of productivity loss that it used to lead to. A 10 member Android engineering team – running/building the app 20 times a day post even a minor change in code, results in 10*20*2.18 = 436min = ~7 hours per day of lost productivity; every day simply waiting for builds. That’s huge, and wasn’t cool until we decided to do something about it.

Slow build times make developers avoid testing on the fly, which resulted in a less stable app for our end users.

Keeping build times low is important for an engineering team’s fulfilment at work; it also indirectly leads to better, more stable products, leading to higher user satisfaction.

So how did we cut down the build time by 95%?

Understanding the problem — Gradle build profile and scans

The first step is to run gradle assembleDebug --profile to get a breakdown of how much time specific parts of your build take. If you want detailed results of why each step took place, and a thread-wise report of all executed tasks, use gradle assembleDebug --scan.

A thread wise Gradle scan of our build. Notice how we are unable to leverage the 12 threads, and most of the build time is spent building the main app module on a single thread

BUD optimisation

1. Bottlenecks

If a project has a lot of modules, it is important to make sure the dependency graph is created well. It is also important to decide where to use implementation and api when creating module-to-module dependencies.

  • If we have the following setup:
    app -> api(modA) -> api(modB) -> api(modC) then, any changes to modC will lead to recompilation of modB, modA and finally, app
  • In contrast, if we have this setup:
    app -> implementation(modA) -> implementation(modB) -> implementation(modC) then changes to modC, will only read to modB recompilation

2. Unnecessary Work

The removal of unnecessary steps from the build is essential when making debug builds.

  • Do not run firebase-perf or newrelic plugins on debug builds. These transform your classes for performance tracking and increase Java/Kotlin compile time 
  • If your development team is mostly using similar test devices and testing only English languages, you can set resConfig to only en, xxhdpi, which will reduce resource packaging for other dpis and languages

Removing these steps from our debug build dropped 40s from our build. Isn’t that amazing?

3. Duplicated Work

We noticed that even without a single line of change, the tasks kotlinCompile and javaCompile were still running for the entire duration it usually takes in a clean build. 

That made us suspect that the compiled jars are not saved for incremental builds.

In the Gradle build scan, you can click on each task and get to know the reason why that task had been run

The culprit? We had fields in that were changing in every build. For example, saving the build timestamp. 

Changes in BuildConfig invalidates all the incremental build jars from the last iteration, and also stops Android Instant Run from working. 

The Result

Our builds are now heavily parallelised, leveraging Gradle parallel processing, since our dependency graph is properly setup now.

Our new gradle build scan

Making changes to deep-down library modules, that are used across the entire app in multiple modules still takes time. However, now we don’t have to wait for 2 minutes to view changes to reflect for as simple a thing as a padding of a button.

When there are only a few changes to our consumer app codebase (without any changes to inner modules), it takes only 7 seconds to build.

Not having ever-changing variables in, in our debug builds, means that Instant Run now works and greatly improves iteration time of UI changes.

Part of our build time optimisation effort also got us up to date with the Android Gradle Build plugin version 3.3 (we were on 3.0 till now). We can now release our app as app bundles and reduce download sizes by 20% for our users.

More for you to read


Deepinder Goyal | September 27, 2019
Hunt for the best UX feedback

Here’s a chance for Product enthusiasts to win a spanking new iPhone 11 Pro Max!


Aman Priyadarshi | September 20, 2019
Reviews 2.0 – tags are a new content currency

Now create and consume reviews in less than 30 seconds.


Deepinder Goyal | September 13, 2019
Say hello to our latest app update

Our engineering and design teams have worked closely over the past weeks to elevate some experiences for you.


Aanchal Singh | September 11, 2019
Women in Tech – Chapter 3

Follow the personal journeys of some of the most incredible Women in Tech at Zomato.