如何调试 OBB 扩展包已替换为 PAD（Play Asset Delivery）的应用程序？

Question

我渴望淘汰我们应用程序老化的 OBB Expansion Pack 系统，并将其替换为闪亮的新Play Asset Delivery（PAD，以前称为 Dynamic Asset Delivery），因此我一直在关注文档。但我对下一步该做什么感到困惑。如何到达可以点击“调试”并找到准备就绪的资源的位置，就像过去我的 OBB 在手机中的 /storage/emulated/0/Android/obb/ 处等待一样？

TLDR：我的答案如下，但如果有一种方法可以通过安装时资源包实现快速调试，我会很高兴。我的答案中描述的当前工作流程需要 1) 等待大约 5-10 分钟来构建捆绑包，2) 构建一个 APKS blob，然后 3) 从拆分安装它。

以下是我了解如何使用即装资源包的旅程记录。我希望我对我的努力的描述能够引起其他困惑的开发人员的一些搜索点击，并照亮他们的道路。

---

一切是如何开始的

我的目标：实现像我在 Android Studio 中点击“调试”按钮时一样无缝的情况，知道扩展已紧密安装在适当的目录中，以便为我们的应用程序提供图片和声音。在这里，我希望点击“调试”并类似地​​找到可供使用的图片和声音，但就在我的资产管理器中。

按照 Expansion Pack 文档的传统，PAD 文档使 --local-testing 听起来轻而易举。但随后麻烦就开始了。

因此，我首先设置了 alpha v0.15捆绑工具，希望体验“快速、迭代周期”，从而避免在开发过程中上传到 Play 商店。到目前为止，一切都很好！我使用 --local-testing 标志生成 APK 集合。

当我连接设备并运行“bundletool install-apk”命令时，混乱就出现了。Bundletool 的内容很少，并且没有太多帮助屏幕。但它吐出了这些文件：

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" 

我认为其中之一可能是我的资产包的名称，“my_asset_pack.apk”或类似的名称。但没有一个是。

因此，我很好奇这些文件中的哪些包含我从基础应用程序资产中分解到资产包中的资产。我识别出了本地化字符串（“de”、“fr”等）。但是我的非本地化媒体呢？（它们可能在base-master_2.apk中吗？）

我还需要做更多的事情才能让这些资产显示出来吗？到目前为止，我的安装就绪资产似乎无法在启动时从资产管理器中获得，所以我一定错过了一个步骤。

编辑：更新以反映名称从 DAD 更改为 PAD。

Answer 1

我不知道 Android Studio 中的情况如何，但在 Intellij IDEA 中，您需要在编辑配置窗口中将“部署”选项从“默认 APK”更改为“来自应用程序包的 APK”。更改此选项后，我可以毫无问题地使用应用程序包调试我的应用程序。

Answer 2

好的，总体来说，我们的命令行将执行 Play 商店在收到我们的捆绑包时通常会执行的工作，将其进行加工并以 APK 格式发布。该捆绑包会生成一团分裂的 .APK，然后这些 .APK 又用于在我们的设备上执行安装。

使用安装资源包安装调试版本

1. 在 AS 中，转到“生成签名包 -> Android 应用程序包”。

2. 使用您的凭据构建调试版本。

3. 使用 Bundletool 1.0 或更高版本：

bundletool build-apks --bundle=./app-debug.aab --output=./my_app.apks --ks <path to my keystore.jks> --ks-key-alias=<keystorealias> --local-testing

4. 使用我们的 .apks blob 进行应用程序安装：

bundletool install-apks --apks=./my_app.apks

5. 点击您新安装的应用程序

6. 运行 -> 将调试器附加到 Android 进程。

7. 在 AssetManager 中享受资产的存在。

但我们是否实现了“快速、迭代的循环”？呃，有点像。大约需要 10 分钟的静默时间才能在 WSL 下的 Dell XPS 上构建该 blob。也许是时候掏出支票簿购买 64 核 Ryzen Threadripper 了。

使用资产包调试新安装的调试版本

这对我有用。在构建捆绑包之前，我暂时将所有资源包资源从 </my_asset_pack_dir> 复制到普通的基础资源目录 /app/src/main/assets/ 中。这样我就可以验证应用程序是否可以通过 AssetManager 访问它们。然后，这些临时文件可以在构建过程中被忽略，或者被脚本删除。

这样，就可以测试资产，而无需等待 10 分钟 .AAB -> .APKS -> 拆分安装。