Mastering Android Dynamic Feature Delivery (3/3)

In my last two posts, I discussed with the basic understanding and core implementations of dynamic delivery. In this last part we will test our sample project and troubleshoot.

3 parts of this blog series

• Part 1: Understanding the problem, solution approach & project setup
• Part 2: Implementation of Dynamic Feature Module
• Part 3: Testing & troubleshooting of Dynamic Feature Module (you are here)

Full Source Code — GitHub.Com

Build the project

I’ve previously mentioned that the customer support module contains six large images (18 MB), resulting in a final .aab file size of 22.5 MB.

So, the size of my main app (base module) is 4.8 MB. After installing this app, you will find a button for downloading the dynamic module. You can then download the dynamic module, which has a size of 17.6 MB, from the Play Store.

Android Dynamic Feature Module Testing

Upload your .aab file to Google Play Internal App Sharing and use the URL to install the app from play store.

Demo Video of Android Dynamic Feature Module Testing

Some life saving tips & troubleshooting

1. Make sure the versions of your common dependencies are the same across modules. You might need the same dependencies in the app module as well as dynamic modules. All common library versions should be the same. Otherwise, you may face unwanted build errors.
2. Ensure that your Java and Kotlin versions are consistent across both the app and other modules.
3. Check the compatible Kotlin version of the dynamic feature dependency. If your project’s Kotlin version is not compatible with the latest dynamic feature library, consider downgrading the library version (if you are unable to update the Kotlin version immediately).
4. If any of your third-party libraries or SDKs has NDK configuration internally, you may need to add a few configurations in the app module’s gradle file (under android). I believe this is not directly related to the dynamic feature module. In one of my projects, I had to add this configuration in the gradle file due to a third-party SDK.

ndk {
    abiFilters.add("arm64-v8a")
    abiFilters.add("x86_64")
    abiFilters.add("x86")
    abiFilters.add("armeabi-v7a")
}

5. If your modules contain duplicate classes, you may encounter errors during the release APK build. I have faced this type of error:

java.lang.RuntimeException: Duplicate class org.intellij.lang.annotations found in modules …

To fix the error I had to exclude the duplicate module from the project:

// build.gradle.kts (dynamic module)
// this configuration will exclude the duplicate classes from my dynamic module

configurations.implementation {
    exclude(group = "org.jetbrains", module = "annotations")
}

6. If your app module contains flavors in the build.gradle file, ensure that you add those flavor names to your dynamic module’s build.gradle.kts file.

// build.gradle.kts (dynamic module)

android {
    ...

    flavorDimensions += "version"
    productFlavors {
        create("dev") {}

        create("stage") {}

        create("live") {}
    }
}

There were three product flavors in my app module (dev, stage, live). That’s why I added these three flavors to my dynamic module.

That’s it! I hope you enjoyed the blogs. Feel free to share your feedback in the comment section.