问题
Eager to retire our app's aging OBB Expansion Pack system and replace it with the shiny new Dynamic Asset Delivery (DAD), I've been following the documentation. But I'm stumped as to what to do next.
My goal is to achieve a situation as seamless as back when I would punch the Debug button in Android Studio, knowing the expansion back was snugly installed in the appropriate directory, to serve pictures and sounds to our app. Here I hope to hit Debug and similarly find the pictures and sounds ready to use, but instead 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 experiencing "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. Bundletool doesn't say much, doesn't have much in the way of a -help screen. But it spat out these files:
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 out from my base app assets. 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 that "as with Android Studio, as with 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.
The mention of the Base Context brings back dark memories of performing occult feats on the Base Context in order to change localization settings at runtime, another notoriously convoluted Android feat. Could this be the answer? And what exactly is going on with those sideloaded APK files? 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.
FakeSplitInstallManagerFactory? Let's pause to appreciate what a Philip K. Dickian concept we have come to. Normally, as someone old enough to remember Java applets, I'm an OOP apologist. But with abstractions like something from "Ubik," what even are we doing? All I want is to publish an app that is bigger than 150 MB.
UPDATE: Been searching for a video walkthrough, as it seems more and more that I should have started by studying the bundle format. But all I seem to find is the detritus of deprecated Codelabs and the broadest, IT manager-facing conceptual overviews: footage of devs with conference headsets, marveling about how awesome it is that Duolingo chopped down their app size.
来源：https://stackoverflow.com/questions/62407887/how-do-i-debug-my-app-in-which-obb-expansion-packs-have-been-replaced-with-play