Universal APK built with ApksBuildCommand includes "shadow.bundletool" in Metadata

[benjaminRomano]

Describe the bug
I have the following gradle code to generate a universal apk given an app bundle using the following artifact: https://mvnrepository.com/artifact/com.android.tools.build/bundletool/0.9.0 (the same used by AGP 3.5).

        BuildApksCommand.builder()
                .setBundlePath(bundle.toPath())
                .setOutputFile(intermediateApks.toPath())
                .setSigningConfiguration(signingConfiguration)
                .setApkBuildMode(BuildApksCommand.ApkBuildMode.UNIVERSAL)
                .setAapt2Command(Aapt2Command.createFromExecutablePath(aapt2))
                .setOverwriteOutput(true)
                .build()
                .execute()

However, when I generate an app bundle with dynamic feature modules, SplitInstallManager cannot find them.
If I run the equivalent command using java -jar bundletool-0.9.0-all.jar, SplitInstallManager detects the fused modules.

I did a diff on the two APKs and found the following difference in the AndroidManifest.xml files.

Working APK:

       <meta-data
            android:name="com.android.dynamic.apk.fused.modules"
            android:value="assets,base,java,kotlin,native,split,url" />

        <meta-data
            android:name="com.android.vending.splits"
            android:value="@ref/0x79030000" />

Broken APK:

        <meta-data
            android:name="shadow.bundletool.com.android.dynamic.apk.fused.modules"
            android:value="assets,base,java,kotlin,native,split,url" />

        <meta-data
            android:name="shadow.bundletool.com.android.vending.splits"
            android:value="@ref/0x79030000" />
    </application>

Bundletool version(s) affected
Version: 0.9.0

To Reproduce
Generate an apks file with both methods, using bundletool from command line and using the BuildApksCommand from the published jar.

Expected behavior
The app bundle generated using ApksBuildCommand
A clear and concise description of what you expected to happen.

Known workaround
Execute command using cli with the fat jar.

Environment:
Mac

[plecesne]

Thanks for reporting the issue.

This seems related to the Relocating packages option from shadowJar which we use in the build.gradle.

I would have expected the shadowJar plugin to only modify the imports, but it seems not to...

[0neel]

We experience a similar issue while using MissingSplitsManagerFactory as described in this doc. It doesn't work because meta-data com.android.vending.splits.required is renamed to shadow.bundletool.com.android.vending.splits.required.

The workaround is to manually add the correct meta-data to the AndroidManifest.xml:

        <meta-data
            android:name="com.android.vending.splits.required"
            android:value="true" />

    </application>

That makes MissingSplitsManager working as expected.

UPD: looks like the issue is fixed in the latest bundletool but still present if the app is deployed to a device using Android Studio.

[plecesne]

This will be fixed in the next release of bundletool and in the subsequent release of Studio canary.
Sorry for the inconvenience.

[shashachu]

Does this same issue affect all dynamic module deployment to device through Android Studio? I'm on AS 3.5 and when I run the app from inside Android Studio and have all our dynamic modules checked in the Run configuration, the SplitInstallManager still says there are 0 modules installed.

When I use bundletool 0.11.0 to build and extract the APK, it works and SplitInstallManager correctly reports that the modules are installed.

[plecesne]

When you install from Studio, do you select to install "APK from app bundle" instead of "Default APK"?

[shashachu]

When you install from Studio, do you select to install "APK from app bundle" instead of "Default APK"?

I did some further testing, and it appears when deploying from AS (using APK from app bundle), I need to kill the app and re-launch it in order for SplitInstallManger to recognize the module is installed. I am calling SplitCompat.install in our Application.attachBaseContext and when downloading from Play Store via an internal track, the module is available without an app restart, so maybe this is something specific to the Android Studio flow?

Edit: I'm happy to file a bug on AGP if this seems like something specific to AS.

Edit 2: Sorry actually I forgot that I locally changed the module to install-time to see if that made a difference. Let me try changing it back to on-demand and see if relaunching the app still fixes the issue.

Edit 3: Ok so when it's an on-demand module, I actually have to select Default APK and re-launch the app for the module to be recognized. Our dev advocate was seeing the same behavior in a sample app, and and she's already going to file a bug on AGP or AS, so I don't believe this is a bundletool issue.

Apologies for all the thrash. :)

[plecesne]

Thank you for the detailed description.
Could you please post the link to the bug once she's filed it? That bug might require a joint team effort to debug.

[plecesne]

Oh also, we don't get notifications for edits, so consider making a new comment for each new information! I almost missed the very valuable information from the edits. Thanks :)

[plecesne]

Now fixed in 0.12.0.