Android builds
summary
Lyft runs two Android apps in a single Git monorepo with 700+ modules, ~700k Java lines and ~50 Android devs, and faces Gradle’s ~20s configuration penalty and fragile incremental behaviour. The solution stack mixes Gradle + Buck today while migrating heavy work to Bazel/Skylark, a build farm with remote build cache and remote execution, plus in‑house CI and analytics. Remote cache carries terabytes (≈5 TB) of traffic, lets CI write shared artifacts, and cuts local build latency and redundant compilation across developers.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 1:51Bash build problems
- 4:39Make drawbacks
- 7:51Maven problems
- 10:19Gradle benefits
- 12:02Gradle as config language
- 13:06Gradle config issues
- 17:43Build API concept
- 20:15Sequential build issues
- 22:45Remote build cache
- 27:42Gradle and performance
- 29:31Blaze and Buck
- 31:38Buck and Skylark
- 34:08Buck as balanced language
- 35:34Buck and incremental builds
- 37:42Buck and remote cache
- 38:46Build system role
- 41:14When to use Bazel
- 42:41Bazel remote cache
- 43:46Remote cache requirements
- 46:17Remote cache implementation
- 48:48Build analytics
- 53:03Additional resources
- 55:58Q&A
related talks
45mScaling Architecture at Lyft
48mMobile Developer Productivity at Scale
43mBetter, Faster, and Stronger CI/CD Pipeline
28mBuilding at Uber Scale
30mModular Android Development
54mFrom Laptop Builds to Advanced CI
43mThe Engineering Playbook for Growing Android Teams
41mDude, Where's My Build? Android CI/CD at Uber