Managing Dependency Hell in a 400-Module Android Project
Article Summary
Erdem Topak from Flink reveals how their Android team scaled from 30 to 437 modules—then discovered 400 unused dependencies silently killing their build times. Here's how they built a custom solution when existing tools failed.
Flink's Android project grew to support 15 engineers working simultaneously, but dependency management spiraled out of control. With 4,652 total dependencies across 437 modules, popular tools like the Dependency Analysis Gradle Plugin required 48GB of memory and 2-3 hours to run, then broke their build. They needed a better approach.
Key Takeaways
- Custom Gradle plugin removed 400 unused dependencies, cutting build times by 15%
- Binary search validation safely removes dependencies in O(log n) time
- ASM bytecode analysis detects actual class usage, not just text parsing
- CI integration runs in 30 seconds, preventing future dependency bloat
- pub/impl/wire/test module pattern enabled 15 engineers to work conflict-free
Building a custom dependency analyzer delivered 15% faster builds and removed 400 unused dependencies in a fraction of the time existing tools required.
About This Article
Flink's Android codebase has 437 modules and accumulated 4,652 dependencies over time. Without a systematic cleanup process, the team couldn't analyze which dependencies were actually needed. The sheer volume made manual review impossible.
Erdem Topak's team built a custom Gradle plugin that uses ASM bytecode analysis to track which classes are actually used across modules. They then used binary search to safely remove dependencies one at a time, validating that each removal didn't break the build.
The DependencyAnalyserTask runs in 30 seconds when added to CI, compared to 2-3 hours for other tools. It successfully identifies unused internal dependencies that can be safely removed and helps prevent future dependency bloat.