Sharing code among multiple projects: the case of internal libraries
summary
Deezer extracts reusable code into private Android libraries organized as three libraries (features, core, design), hosted to an internal Nexus and released together under a single version. Development uses a mono-repo for Android libs, a two-week release train with nightly snapshots, and a CI trick where apps can point to a locally published artifact by toggling a property and using a local Maven publish with package-name suffix. Authentication reuse succeeds; a poorly extracted sync feature fails until replaced by an API-only module and separate implementations.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 3:41Requirements for shared code
- 5:25Libraries as modules
- 8:17What to put in libraries
- 11:50Organizing libraries
- 13:19Design system example
- 15:05Version control approach
- 17:17Distribution and versioning
- 18:45Publishing process
- 19:26Development workflow
- 22:17Local development example
- 24:24Documentation strategy
- 25:50Lessons learned
- 28:21Key takeaways
related talks
49mHow to share code using internal libraries
22mSharing features between applications: a postmortem
43mLibrary Developer Confidential
37mAndroid Librarian's Guide: Building Robust Libraries a…
44mBuilding and Publishing Android Libraries the Missing Guide
40mModularizing Android Applications
45mCode Once, Use Everywhere: Building Shared Libraries for Multiple Projects
32mScaling Android Development without a Monorepo