Private libraries in Android — how to manage them.
Article Summary
Jean-Baptiste Vincey from Deezer reveals how their team manages private Android libraries across multiple apps—without the chaos. Their approach handles 3 major libraries with bi-weekly releases and keeps dependencies aligned.
This is part 2 of Deezer's series on private libraries, focusing on the practical implementation details. The team manages Core, Design, and Server-driven UI libraries used across their Android applications, with each library maintained as an independent Gradle project with its own Git repository.
Key Takeaways
- Bi-weekly release train with semantic versioning: major.minor.patch structure
- Nexus repository for distribution, Jenkins CI for automated nightly snapshot builds
- Design-snapshot branches let apps integrate unreleased library changes without blocking main development
- Local publishing with _local suffix enables testing library changes before release
- Japicmp generates API diff reports between versions for clear release notes
Deezer's structured approach to private library management enables fast-paced multi-app development with consistent components, though managing dependencies across multiple libraries remains challenging.
About This Article
Deezer's private libraries are scattered across different applications, which creates dependency misalignment issues. When libraries depend on each other but apps use different versions of shared dependencies like Kotlin and AndroidX, conflicts happen.
Jean-Baptiste Vincey's team looked into moving all libraries into a single Git repository. This would make it easier to manage how the libraries depend on each other while keeping each module independent and maintaining separate release cycles.
A monorepo setup would stop version conflicts between the Core, Design, and Server-driven UI libraries. The bi-weekly release train and snapshot branch workflows that each library currently uses would stay in place.