Traveloka Android Dynamic Feature Module Migration
Article Summary
Anisha Inas Izdihar and Yusuf Cahyo Nugroho from Traveloka cut build times by 37% and saved users 15MB of storage. Here's how they migrated 26 modules to Android's Dynamic Feature Module framework.
Traveloka's Android team spent two years migrating their app to Dynamic Feature Modules (DFM), allowing features to be delivered conditionally based on user locale and device configuration. This deep dive covers the technical implementation, performance wins, and real problems they hit along the way (including a two-month debugging saga with an obfuscated SDK).
Key Takeaways
- Full build time dropped 36.82% by excluding unused feature modules
- Incremental builds improved dramatically with no dependent module recompilation
- Initial download size reduced by 3.5% for international users
- 26 of 35 product modules now use DFM with three delivery options
- Created fallback Module Listeners using Java Reflection for uninstalled features
Migrating to DFM delivered measurable wins in build performance and app size while enabling locale-specific feature delivery across regions.
About This Article
Traveloka's digital product top-up feature couldn't complete its DFM migration. An obfuscated third-party SDK failed to find native libraries after the module was relocated, and it only returned a generic error code. The team spent two months tracking down what went wrong.
The team decompiled and modified the SDK using Recaf to examine its checksum calculation. This revealed that the native library path was actually the problem. They validated their theory before deciding to postpone the migration.
After migrating the Budget Planner and Gift Voucher modules with conditional and on-demand delivery, Traveloka cut the initial app download size by 3.5% for non-Indonesian users. Users can now save up to 15MB of storage space after installation.