My goal is to reach a situation in which I can run Debug from Android Studio, then have all the pictures and sounds from my asset pack appear for use in my Asset Manager.
In the tradition of the Expansion Pack docs, the DAD docs make –local-testing sound like a breeze. But then the trouble begins.
So I’ve set up the very alpha bundletool in hopes of "quick, iterative cycles" that will avoid having to upload to Play Store during development. So far so good! I used the –local-testing flag to generate a collection of APKs.
The confusion set in when I connected my device and ran the "bundletool install-apk" command. These files were produced.
ADB >> OK Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-xxhdpi.apk" Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-master_2.apk" Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-de.apk" Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-fr.apk" Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-nb.apk" Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-sv.apk" Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-arm64_v8a_2.apk"
I thought one of them might be the name of my asset pack, "my_asset_pack.apk" or something like that. But none is.
So I am curious as to which of these files contains the assets I have broken off. I recognize the localization strings ("de", "fr", etc.). But what about my non-localized media? (Could they be in base-master_2.apk?)
And more importantly, how do I bring the assets from my asset pack module (app_assets) into the app for use? The docs do not say what to do next in Android Studio, only (oddly enough) in Unity.
But OK, let’s assume the same idea applies to Android Studio as to Unity. If I run Debug in AS, will the additional assets (not sure which of these .apk files they are found in) be combined with my base assets?
In other words, is that all I need to do to make these assets show up? Or, alternatively, do I need to delve deeper, into the complicated world of FakeSplitInstallManagers as described in this Codelab and suggested here as somehow still a necessary part of the process?
So far my ready-upon-install assets don’t seem to be available from the Asset Manager so I must be missing a step.
In trying to understand these split APKs, and what they represent, I don’t understand whether I also need to make the Manifest changes, etc. described in that Codelab. I do see suggestions out there that the new –local-testing flag introduced in bundletool v0.13 has done away with the need for these, but it seems like I am not alone in needing an ELI5 on this.
Any help much appreciated. The new feature looks great, but the docs feel like they have gaps in them and the bundletool is more laconic than verbose.
UPDATE: Still trying to figure this out. The docs for SplitInstallManager make it sound like I need to set one of these up for my application context.
As long as you enable SplitCompat for your base application context
and the activities in your dynamic feature module, after a request for
an on demand module reports as INSTALLED, you can start using its code
and resources as if it were a part of the base APK.
This brings back dark memories of messing with the Base Context in order to change application language at runtime, another notoriously convoluted Android feat. Could this be the answer? And what is going on with those sideloaded APK files exactly? Hopefully I will figure this out.
UPDATE: Maybe this is the answer. The docs for the "FakeSplitInstallManager" say it will let me grab the split APKs from a directory (the /sdcard, I presume) while pretending that it is a Split Install Manager.
FakeSplitInstallManager? Let’s pause to appreciate what a concept that is. Normally I’m an OOP apologist. But with abstractions like this…