Modernizing Our Android Build System Part II: The Execution
Article Summary
Dropbox migrated 75 Android modules from a custom build system to Gradle without breaking their engineering team's workflow. Here's how they pulled it off.
After deciding to abandon their custom BMBF build system (covered in Part I), Dropbox's mobile platform team faced the challenge of actually executing the migration. This meant preserving key features like layered dependencies while unlocking Gradle's flexibility across their entire Android codebase.
Key Takeaways
- Built layered dependency verifier in Kotlin, gaining Gradle caching for free
- Automated 75 module migrations with 500 line Python script
- Integrated Watchman to skip unnecessary code generation on every build
- Reduced P50 local build times by 20% through smart caching
- Zero downtime migration via overcommunication and post release timing
Dropbox cut build times by 20% while migrating their entire Android codebase to standard Gradle, proving that large scale tooling changes don't require engineering disruption.
About This Article
Dropbox's BMBF build system had a non-standard directory structure across 75 modules. This meant engineers had to write extra boilerplate in settings.gradle files whenever they created new modules, which slowed things down.
David Chang's team built a 500-line Python script that handled the migration automatically. It moved code into standard Gradle directories, updated imports in the source files, and fixed project dependencies without requiring any manual work.
Creating new modules is now simpler. Engineers just apply common.gradle configurations with minimal boilerplate. The team also got rid of redundant code generation tasks that used to run on every build, even when nothing had changed.