Journey of the Android white label process
summary
Company runs 80 modular in‑app modules and ships 70+ white‑label projects biweekly, so the pipeline focuses on concrete fixes: use Localize for translations, expose a sealed appConfiguration interface to enforce required overrides, split optional SDKs into lib‑feature / lib‑default / lib‑opt‑in with a service locator fragment factory, publish common libraries to Nexus, and parallelize CI to cut release time from hours to under 30 minutes (config cache trims config time to ~4–5s).
AI-written summary · about
chapters (23)
- 0:00White labeling Android apps
- 1:27Why white labeling for Yoki
- 3:10White label vs core apps
- 4:16Rebranding with localization
- 6:23Managing colors and drawables
- 8:07Handling secrets and configs
- 9:10Interfaces for flexibility
- 10:33Feature customization via backend
- 11:16Optional dependencies and locator
- 12:39Splitting libraries for SDKs
- 15:47White label app architecture
- 16:50Organizing projects and modules
- 18:15Decoupling white label from core
- 19:21Excluding dependencies
- 20:46Resource merging in builds
- 21:49How merging affects white labels
- 23:15White label not a dependency
- 24:20Code owners for teams
- 25:02Releasing white label apps
- 26:06Publishing libraries to Nexus
- 27:49Parallel builds and releases
- 28:52Future build improvements
- 29:32Q&A
related talks
41mWrite once, ship multiple times
40mScaling Android Apps
37mA Complete Journey of Android Modularisation
27mModularising the right way
39mScaling an Android App from 1 to 100 developers with modularization.
30mModular Android Development
32mBuild a modular Android app architecture
35mRelease Android apps globally with no headache and minimum stress