Find Gradle Build Bottlenecks with Android Studio Build Analyzer

Your build is slow, but you do not know where the time goes

Your Gradle build just crossed the two-minute mark, and you have no idea whether the time is spent configuring projects, compiling Kotlin, or processing resources. Adding more modules seems like the obvious fix, but modularizing without data can make the build slower if you split the wrong way.

Android Studio's Build Analyzer shows a task-level breakdown after a Gradle build finishes, so you can decide whether to reorganize modules, adjust gradle.properties, or leave the build alone.

What Build Analyzer measures

Build Analyzer opens in the Build tool window after a Gradle build completes. It displays a task duration graph and flags long-running configuration or execution tasks. The configuration phase is when Gradle evaluates build scripts and decides which tasks to run; the execution phase is when those tasks actually run, such as compiling code or dexing. Android Gradle Plugin (AGP) version determines how much detail appears; older releases may show fewer suggestions.

Worked example: check configuration time

1. Open your project in Android Studio.
2. Run a clean build from the terminal inside Android Studio:

./gradlew clean assembleDebug

Where: project root in the Android Studio terminal. Permissions: write access to the project directory and execute permission on gradlew. Expected check: the build finishes and the Build Analyzer tab appears in the Build tool window. Risk: a clean build takes longer than an incremental build, so do not compare its timing to a previous warm build.

1. Open Build > Build Analyzer. Look for a warning about configuration time and note the reported duration.
2. To test whether configuration on demand helps, add this line to gradle.properties in the project root:

org.gradle.configureondemand=true

This tells Gradle to configure only the projects needed for the requested tasks, rather than every project on every build.

1. Sync and run the same clean build again. Compare the configuration time in Build Analyzer.

Rollback: if builds fail or variants disappear, remove or comment out that line in gradle.properties, sync again, and rebuild.

Risk: configuration on demand can break builds where one module expects another module to be fully configured first. Verify debug and release variants after enabling it.

Limitations and what not to compare

Build Analyzer reflects one environment and one cache state. A cold build and a warm build should not be compared directly; the warm build will almost always look faster. Some long tasks, such as dexing or resource processing, are inherent to project size and language features, not configuration bugs. Advanced insights sometimes require the Gradle Enterprise plugin and a compatible Gradle version, which are not part of the free local analyzer.

Decide before you refactor

Before splitting modules, check the AGP version in the module-level build.gradle file and confirm Build Analyzer shows configuration overhead, not just execution overhead. If execution dominates, moduleization may not help; if configuration dominates, configureOnDemand or separating independent modules is more likely to pay off.

Closing

Run one clean build, open Build Analyzer, change one setting, and run another clean build. Keep the change only if the analyzer shows a real reduction in the phase you targeted, and verify all build variants still succeed.