Scaling Android CI: From 44 → 10 minutes — A Deep Dive into Build Time Optimization and Best…

Summary

An Android monorepo’s CI pipeline averaged about 35 minutes in its build phase, with a P90 of roughly 44 minutes, as repeated dependency downloads, environment-driven invalidations, variant bloat, and machine limits increased work. The team reworked caching with branch- and architecture-aware keys, release/develop fallbacks, cached SDK and dependency data, and a Gradle Remote Cache, while filtering repositories and restricting CI to required variants. It also tuned 32GB runners to a 16GB heap and 12GB Metaspace, disabled configuration-cache saves in ephemeral CI, upgraded Kotlin, AGP 8.10.1, and Gradle 8.11.1, and moved critical workflows to Apple Silicon. Gradle tasks fell from 3399 to 2745, while remote-cache hit rates reached P50 44% and P90 56%. After the Apple Silicon refresh, total CI time reached P50 10 and P90 11 minutes, average credits per build dropped from 55 to 43, and a comparable rollout window saved about 5800 credits.

Takeaways

1. 1

   Branch-level cache saves were avoided on every run under the 2-credits-per-minute plan because saving could take 1–1.5 minutes and sometimes about 3 minutes; authoritative develop and release caches were refreshed through back-merges instead.

2. 2

   A Gradle Remote Cache running on a small EC2 instance with 8GB RAM and a 256GB SSD produced incremental-build hit rates of P50 44% and P90 56% in the reported results.

3. 3

   Restricting CI to required release variants reduced the Gradle task graph from 3399 to 2745 tasks, while configuration-cache saving was disabled after scans showed about 30 seconds spent saving data that ephemeral CI did not reuse.