Architecture for AppBundles
summary
A million‑line Android app is split into tiny feature libraries on top of a small base APK, then wired to load on demand via Play Core dynamic delivery, cutting installed size (Google reports ~30%) and isolating rare flows (an identity upload used by ~5% of users). Dependency injection uses Dagger component dependency patterns so dynamic modules get singletons from the base; runtime entry points are activities/fragments (class reflection only if needed). Testing requires the internal test track and Play app signing; it works but has manifest, loading and UX caveats.
AI-written summary · about
chapters (15)
- 0:00Start
- 0:33What dynamic feature modules mean for my existing architecture?
- 3:11Problems?
- 8:20Let's see some code.
- 10:01Sometimes you display things from different modules, on a single Activity.
- 20:18Dynamic Delivery Dynamic Feature Modules
- 23:17Dynamic Feature Modules.
- 23:56Dynamic Feature modules depend on your base app'. Not vice versa.
- 24:54You don't have to change your architecture to support AppBundles - you can benefit from them without much of the effort.
- 25:29Purpose of our modular approach: good separation, lack of coupling between features enforced in compile-time.
- 26:12Purpose of Dynamic Feature Modules: smaller APK size (good separation coming more as a 'side-effect').
- 31:21Easy way - module's 'entry point' being Activity/ Fragment.
- 35:17Start using AppBundles.
- 35:54Dynamic Feature Modules you may need them, but you may not.
- 37:05Don't treat it like it's the "ultimate" way of modularizing your app.
related talks
35mArchitecture for App Bundles
30mDynamic App Modules: Building For the Next Billion
32mBuild a modular Android app architecture
42mForget everything you know about APKs
43mModularization for dynamic delivery
35mOptimize App Downloads with Android App Bundle and Dynamic Delivery
40mThe future of apps on Android and Google Play: Modular, instant, and dynamic
20mBundling an app in an instant