Breaking the build
summary
Companies report massive scale problems: one codebase has 500 modules and another had 40–50 minute builds before changes. Teams measure time-to-merge and build medians, use Gradle Profiler for repeatable benchmarks, Graph Assert to find high betweenness modules, and Foundry or custom convention plugins to generate modules. Common-module bottlenecks get class-by-class extraction, plugins get published as binaries to avoid build churn, and some teams migrate to Bazel or watch the Declarative Gradle EAP for long‑term gains.
AI-written summary · about
chapters (16)
- 0:00Welcome
- 2:28Android build 2025
- 5:46Dedicate resources to builds
- 8:53Build performance metrics
- 12:20Modularization strategies
- 16:57Gradle plugins and static analysis
- 18:00Bazel on Android and iOS
- 23:56Bazel migration worthiness
- 25:08Custom Gradle plugins
- 27:19Declarative Gradle future
- 28:22Gradle abstraction debate
- 29:25Bottleneck modules breakdown
- 31:33Gradle best practices
- 35:08Monorepo vs polyrepo builds
- 38:00Platform team challenges
- 40:52Q&A
related talks
36mImproving Gradle Builds
40mNail your Gradle build time
37mThe Build Shrugged
35mGradle recipes for reducing your build times
44mGradle: The Build System That Loves To Hate You
39mWorking with Alternative Build Systems
35mGradle + CI vs. Modulezilla: Winning the War
37mModularization - flatten your graph and get the real benefits
