Modernizing Our Android Build System Part I: The Planning
Article Summary
Dropbox's Android build system was so painful that engineers 6+ months in still couldn't create new modules. Time for a rebuild.
The Dropbox Mobile Platform team spent 4 months evaluating whether to stick with their custom BMBF meta-build system, migrate to pure Gradle, adopt Bazel, or switch to Buck. This deep dive covers their rigorous evaluation process and the tradeoffs that shaped their decision.
Key Takeaways
- Bazel delivered 81s cached builds vs 252s for BMBF, but lacked Android Studio support
- BMBF broke Gradle incremental builds by regenerating files every time
- Pure Gradle won: industry standard, low migration cost, immediate access to new features
- Buck ruled out due to poor community support and need for dedicated 3 person team
- Team built working prototypes of each system to compare real build performance
Dropbox chose Gradle over faster alternatives because developer experience and ecosystem maturity outweighed raw build speed gains.
About This Article
Dropbox's BMBF meta-build system was hard to learn and full of surprises. It required a very specific file and folder structure that made it difficult for developers to be productive and create modules in their Xplat repository.
David Chang's Mobile Platform team built sandbox prototypes to test Gradle, Bazel, and Buck. They measured clean builds, cached builds, no-op builds, and incremental compilation times across different scenarios.
Gradle achieved 28.6-second no-op builds and 124-second incremental builds for main modules. BMBF had 20-30 second no-ops and 181-second incremental times. Gradle also uses industry-standard tooling and requires less maintenance work.