Traveloka Android Dynamic Feature Module Pilot Project
Article Summary
Anisha Inas Izdihar and Yusuf Cahyo Nugroho from Traveloka tried implementing Dynamic Feature Modules in 2019 when documentation was scarce and critical tools were broken. Their workarounds got creative: they literally modified Google's compiled jar files.
This is part one of a three-part series documenting Traveloka's pilot project to adopt Android's Dynamic Feature Module framework. The team faced multiple blockers including incompatible libraries, broken resource shrinking, and a tightly coupled codebase that wasn't ready for modularization.
Key Takeaways
- Resource shrinking was incompatible with DFM, forcing manual unused resource removal each release
- Team modified Android Gradle Plugin jar files using bytecode editor to bypass restrictions
- Built custom Gradle plugin to auto-generate full package names for cross-module resources
- Dart & Henson navigation library required PR contribution to add DFM support
Traveloka successfully completed their DFM pilot by solving four major compatibility issues through custom tooling, library contributions, and manual workarounds that they still use today.
About This Article
Traveloka's pilot module and App module were tightly coupled, which blocked the decoupling needed for Dynamic Feature Module adoption. Circular dependencies between the App module and DFM made this impossible to fix.
The team removed all App module references to the pilot module, then flipped the dependency structure so the pilot module depended on the App module instead. This let them build independently.
With the new architecture in place, the app could be built without the pilot module. This set up Traveloka's multi-module codebase for successful DFM integration.