Revamping the Android Testing Pipeline at Dropbox
Article Summary
Dropbox cut their Android CI pipeline from 75 minutes to 25 minutes without switching build systems. Here's how a team of 60+ mobile engineers solved testing at scale.
As Dropbox's Android team grew from 12 to 60+ engineers, their testing pipeline became a productivity killer. Engineers started writing fewer tests and bundling changes into massive PRs to avoid the wait. The Mobile Foundation team rebuilt their entire CI approach using selective testing, Firebase Test Lab, and smart parallelization.
Key Takeaways
- Borrowed AndroidX's Affected Module Detector to run only necessary tests per PR
- Migrated from custom Python tooling to Gradle, Kotlin, Firebase Test Lab, and Jacoco
- Sharded 400 modules across 10 VMs, testing just 2 modules per VM on average
- Reduced worst case compute from 75 minutes to 35 minutes with better parallelization
- Open sourced their AffectedModuleDetector plugin for the Android community
By testing only affected modules and leveraging cloud infrastructure, Dropbox achieved a 67% reduction in CI time while supporting 3x team growth.
About This Article
Dropbox's custom Python code coverage toolchain was unreliable and hard to work with. It would break without warning and needed constant maintenance that the team couldn't always prioritize.
The Mobile Foundation team switched to Jacoco, an industry-standard tool for coverage verification. They moved the custom logic to Kotlin and built a data model to pull coverage data from Firebase and local tests.
Switching to Jacoco cut down on maintenance work and fixed the coverage infrastructure problems that had been silently breaking. Engineers could then spend time on other infrastructure improvements that mattered more.