Play Asset Delivery实践篇 (踩坑-2021.11.27修改)

闲聊

最近一段时间，开始负责一个游戏项目安卓SDK对接工作，又是熟悉的味道还是那个配方。从游戏研发边缘成员折腾回安卓SDK对接工作中(再次入坑)。

马上快8月了Google 上架游戏政策又发生变化，手中对接游戏主要发往海外。所以Google的要求我们还是要满足的。想想发往国内的游戏渠道，真是幸福。

废话说完，进入今天正题。针对Google 8月份新规 游戏这块需要作出调整以应对新规，正好做个记录，以踩坑者的角度去记录一下过程。

上架Google时间轴

开发者应该着重关注8月份起新政策。新应用8月份上架Google Play 强制API>=30，老应用截止11月份前强制API >=30。同理、同样的操作还有 Play结算库要升级到3.x+版本才被允许上架商店。可参考另一篇博客Google Play-v4.0结算库

8月起，新应用需要使用 Android App Bundle 才能在 Google Play 中发布。对于超过150MB的新应用，谷歌提供两种方式供大家使用，分别是Play Feature Delivery 和 Play Asset Delivery

Android App Bundle 简介

Android App Bundle 是官方提供一种新发布格式(后缀.aab),其中包含应用的所有经过编译的代码和资源。 APK 生成及签名全部交由 Google Play 来处理。

Google Play 会根据你上传的 App Bundle,针对每种设备生成配置，并提供经过优化的 APK，因此只会下载特定设备所需的代码和资源来运行你的应用。

你可以不必再构建、签署和管理多个 APK 来优化对不同设备的支持，而用户也可以获得更小且更优化的下载文件包。

上传 app bundle 时，如果 Play 管理中心发现应用下载大小超过 150MB会收到如下错误提示(我不死心，已经大胆的试了一下。看官们就别在试水了)

有一点需要注意，超过150MB的应用。 Android App Bundle 不支持 APK 扩展 (.obb) 文件，只支持 Play Feature Delivery和Play Asset Delivery两种方式用来替代传统的.obb文件

Play Feature Delivery和Play Asset Delivery

Play Asset Delivery (后续简称-PAD)将 app bundle 的优势带到游戏中。它允许超过 150 MB 的游戏替换旧版扩展文件 (OBB)，方法是将包含游戏所需的所有资源的单个文件发布到 Play。

PAD 提供了灵活的分发模式、自动更新、压缩和增量修补功能，并且可免费使用。使用 PAD，所有资源包均在 Google Play 上托管和提供，因此你无需使用内容分发网络 (CDN) 向玩家提供游戏资源。

Play Asset Delivery 使用资源包，资源包由资源（如纹理、着色器和声音）组成，但不包含可执行代码。通过 Dynamic Delivery，可以按照以下三种分发模式自定义如何以及何时将各个资源包下载到设备上：安装时分发、快速跟进式分发和按需分发。

Play Feature Delivery(后续简称-PFD)功能模块的独特优势在于能够自定义应用的不同功能如何以及何时下载到搭载 Android 5.0（API 级别 21）或更高版本的设备上。例如，为了减小应用的初始下载大小，你可以将某些功能配置为按需下载，或者只能由支持特定功能（比如拍照或增强现实）的设备下载。

虽然将应用作为 App Bundle 上传时，默认即可获得高度优化的下载文件，但如需使用更高级和可自定义的 Feature Delivery 选项，你就必须使用功能模块对应用的功能进行额外的配置和模块化处理。也就是说，功能模块为你提供了用于创建模块化功能的基块，而你可以将这些功能配置为按需下载。

PAD和PFD推荐选择方式

这两种方式，游戏类应用更建议是用PAD形式，为什么 ？我产生过这样的疑问！！！从字面上来看PAD 翻译过来就是应用资源下发。常规的U3D或者COCOS引擎接入SDK 给到安卓或者IOS，通常是以资源的(Asset)形式输出的，这种方式更符合PAD设计 。

而PFD偏向非游戏类应用(例如电商应用)，它的设计更倾向于模块化性质。如果游戏用了模块化方式无形中增加了游戏代码和设计的成本。所以游戏类型应用不建议PFD方式。

PAD分发模式

• install-time 资源包在用户安装应用时分发。这些资源包以拆分 APK（APK 集的一部分）的形式提供。它们也称为“预先”资源包；你可以在应用启动时立即使用这些资源包。这些资源包会增加 Google Play 商店上列出的应用大小。用户无法修改或删除这些资源包。

• fast-follow 资源包会在用户安装应用后立即自动下载；用户无需打开应用即可开始 fast-follow 下载。此类下载不会阻止用户访问应用。这些资源包会增加 Google Play 商店上列出的应用大小。

• on-demand 资源包会在应用运行时下载:Google Play 商店会以归档文件（而非拆分 APK）的形式提供配置为 fast-follow 和 on-demand 的资源包。这些资源包随后会在应用的内部存储空间中展开。你可以使用 Play Core API 查询以这种方式提供的资源包的位置。
  应用无法假设这些文件的存在或其位置，因为它们可能会被用户删除，或由 Play Core SDK 在游戏会话之间移动。尽管这些文件可由应用写入，你也应将其视为只读文件，因为资源包补丁程序依赖于这些文件的完整性。

PAD下载大小上限

Asset Pack 因具有较高的大小上限而成为大型游戏的理想之选

• 每个 fast-follow 和 on-demand Asset Pack 的下载大小上限为 512 MB。

• 所有 install-time Asset Pack 的总下载大小上限为 1 GB。

• 一个 Android App Bundle 中的所有 Asset Pack 的总下载大小上限为 2 GB。

• 一个 Android App Bundle 中最多可以使用 50 个资源包。

PAD分发模式选择

游戏在使用 PAD会面临三种模式的选择分别对应着、 安装时分发（install-time）、快速跟进式分发（fast-follow）和按需分发（on-demand）！！！

建议用安装时分发（install-time）方式，对于游戏和SDK压力非常小,清晰明了。基本不需要额外的代码和逻辑。按分发模式文档配置即可简单方便。安装时分发模式的总下载大小为 1 GB，一般的游戏基本不会超过此范围。可以作为初期使用。

PAD实践操作

前置工作

• 新游戏 targetSdkVersion >=30 才能提交google play

• 必须将 Android Studio 升级至 4.1.0 及以上版本，才能使用此功能

• Android Gradle 插件的版本更新为 4.0.0 或更高版本的同时，还需要使用对应的 Gradle 版本。查看 Android Gradle 插件与 Gradle 版本对应关系请见 Gradle文档

install-time模式配置

• 建好application应用,在同级目录新建一个名为install_time_asset_pack 的Modle目录。Asset Pack 名称规范、必须以字母开头，并且只能包含字母、数字和下划线。

• install-time-asset_pack/build.gradle 文件并添加以下代码。需要指定 Asset Pack 的名称，并且只能指定一种分发类型。

apply plugin: 'com.android.asset-pack'

assetPack {
    // packName 的名称可更改，但是要和配置对应上
    packName = "install_time_asset_pack" 
    dynamicDelivery {
    //只能指定一种类型，对应PAD分发模式
        deliveryType = "install-time"  
    }
}

• 然后app/settings.gradle加上如下配置

include ':install_time_asset_pack'   //命名要和packName一致（这段配置可复制）

• 接着在app级别的build.gradle android字段内配置依赖属性

android {
 //指定了install-time模式，其他两种模式大同小异
 //命名要和packName一致
    assetPacks = [":install_time_asset_pack"] 
}

• 最后app/build.gradle 添加远程依赖库

dependencies {  
    implementation 'com.google.android.play:core:1.10.0'
}

• 游戏占用大的资源复制到install_time_asset_pack文件夹内assets里面，下面拿 cocosCreator引擎资源为例，游戏给到我这里的资源大文件占用都在安卓assets路径下。

• 生成AAB

⚠️此时生成AAB是未签名,仅供测试用。上传到谷歌上会提示该文件未签名

• 注意事项⚠️

  Unity引擎不要把bin.Data文件放到install-pack/assets下,容易导致报错或者游戏主场景出问题(下图正确展示)

本地测试Play Asset Delivery

测试没问题的标准！！！aab通过bundletool转换为apks能正常安装，能正常进入游戏 ，各个游戏功能点正常。

注意一点：使用aab转换成apks测试，是如果不指定签名 ，会用安卓默认签名。可能会导致Google支付拉不起，详细用法如下链接：Google文档中bundletool使用

上传谷歌商店测试

本地测试没问题后，建议上传到Google 商店真实的系统的测试一遍。谷歌上传应用时候开启了签名计划，需要秘钥才能提交，按下面三图生成一个名为private_key.pepk秘钥，把生成的秘钥提交至GP，添加测试计划，然后发布内部Beta版供测试需要。

把aab成功上传到GP后台，会看到如下类似内容，说明上传内容是没问题的。后台会根据你上传包体包含资源进行分发

解惑踩坑过程中出现的问题

问题一：为什么生成出来的AAB 依旧是很大(超越了150MB)？

答: 先通过两种图做个比较便知分晓，下图是正常没有进行分包的，能看到base里面直接600多mb，这种aab提交GP 会出错，错误内容上面已经展示过了

而下面是经过install-time分发模式分包后的样子 ，可以看到base文件夹其实不到12mb。资源被分到了 install_time_asset_pack文件下。这种方式aab大小没有变化还是600mB, 但是提交Google Play既不会提示出错， 还能正常对外发布。

为什么第二种方式没有问题? 你上传的aab包整体大小没变还是600mb ，但是aab已经包含了分包后的内容，只要你上传到GP后台，剩下内容例如 APK生成及签名、下发设备等全部交由 Google Play 来自动处理。

aab后缀格式本质和apk没区别 是个zip包，当用户实际从Google Play Store点击安装的时候，根据用户设备信息，GP后台服务器通过bundletool工具 下发符合这个设备的apks文件

问题二：文档中明明提到了分发模式有读取路径的操作你为什么没有这个逻辑

答： 如果没有特殊逻辑需求下，只要你gradle远程依赖了core库，路径读取等相关操作 core库自动帮你解决了。Play Core库的作用 就是运行时执行了几个操作，操作内容如下所示：

• 下载对应国家的语言资源

• 管理功能模块分发

• 管理资源包

• 触发应用内更新

• 请求应用内评价