Multi-Module Gradle Builds and Build Optimization

A 3-minute incremental build, run 40 times a day by 20 developers, is 40 developer-hours lost daily. Build speed is productivity. Most wins come from measuring, enabling caches, and avoiding module structures that force unnecessary recompilation.

Where build time goes

Measure first

• Build Analyzer in Android Studio identifies slow tasks and plugins.
• Gradle build scans (--scan) show timelines, cache hits and configuration time.
• Benchmark typical scenarios: clean build, an ABI change in a core module, a non-ABI change in a feature module.

High-impact settings

# Reuse configuration results between builds
org.gradle.configuration-cache=true
# Reuse task outputs from previous builds (local, optionally remote)
org.gradle.caching=true
# Run independent module tasks in parallel
org.gradle.parallel=true
# Give the daemon enough memory (tune for your machine)
org.gradle.jvmargs=-Xmx6g -XX:+UseParallelGC -Dfile.encoding=UTF-8
# Smaller, non-transitive R classes: changes in one module's resources recompile less
android.nonTransitiveRClass=true

Recent AGP versions enable some of these by default (non-transitive R classes, for example). Check what your versions default to, and verify that plugins are configuration-cache compatible.

Prefer KSP over kapt

kapt generates Java stubs and is significantly slower. Hilt, Room and Moshi support KSP. Migrating annotation processors to KSP often gives large wins in modules that use them.

Module structure choices

• implementation over api: limits recompilation of consumers when internals change.
• API/impl splits for frequently changed features used by others.
• Avoid a giant "common" module that everything depends on: one change rebuilds the world.
• Pure Kotlin/JVM modules for domain logic. They build and test faster than Android library modules.
• Convention plugins instead of subprojects { } or allprojects { }, which slow configuration and break isolation.

Build script hygiene

// ❌ Runs at configuration time on EVERY build (even unrelated tasks)
val gitSha = Runtime.getRuntime().exec("git rev-parse --short HEAD").inputStream.reader().readText().trim()

// ✅ Lazy provider evaluated only when needed (configuration-cache friendly)
val gitSha = providers.exec { commandLine("git", "rev-parse", "--short", "HEAD") }
    .standardOutput.asText.map { it.trim() }

• Use lazy APIs (register, providers), not create, and don't read files at configuration time.
• Disable unused build features per module (buildConfig, aidl, renderscript).
• Keep dependencies and plugins up to date. Gradle and AGP improve performance regularly.

CI builds

• Cache Gradle home and the build cache between runs (for example with gradle/actions/setup-gradle).
• Consider a remote build cache shared by CI and developers, populated by trusted CI builds.
• Run only affected modules' tests on PRs in large projects.

Typical wins

Frequently asked questions

Conclusion

Fast Android builds come from measuring, enabling configuration and build caches, parallel execution, KSP, non-transitive R classes, sensible module boundaries with implementation dependencies, and lazy build scripts, plus caching in CI.

Next step: decide how far to share code across platforms with Compose Multiplatform vs Kotlin Multiplatform.