Android App Bundle 适配概览
Google 在 2018 年发布了 Android App Bundle (AAB) 这种新的发布格式。Google Play 的最新政策要求在 2021年 8月后新上架的 App 必须按照 Android App Bundle 方式进行打包发布。已经发布的 App 暂时没有影响。
什么是 Android App Bundle
Android App Bundle：Google 推出的新的发布格式。跟传统的 APK 区别在于，Google Play 用 AAB 来批量生成适用于各种设备的 APK，并根据实际用户下载时的设备配置，使用户只需下载对应的 APK。这种发布方式可以减少 APK 大小，并且避免用户安装很多实际不需要的资源。
Play App Signing：由于 APK 的生成改为由 Google Play 完成，自然 APK 的签名也由 Google Play 完成。
Play Feature Delivery：Google 的插件化版本。Feature module 内包含代码和资源等内容，可以根据需要决定什么时候下载和使用。
Play Asset Delivery：Asset 资源分包，取代以前的 APK Expansion File (OBB)。由于 Google Play 有 APK 100MB 限制，以前是用 OBB 文件来解决资源过大的问题。但是 OBB 没有签名验证，也无法根据不同设备加载不同资源，所以 Play Asset Delivery 就是为了针对 Asset 资源分包而存在的。
Android App Bundle Format：
Base Module 就是主包。
Dynamic Feature 就是 Play Feature Delivery。
Asset Pack 就是 Play Asset Delivery。
发布流程的变化
项目配置要求
Android studio 3.2 以上版本
Gradle 插件版本 3.2.1之后
2020-08-01之后 Google Play 的新建项目只支持 AAB 格式文件
Google Play发布AAB格式文件注意事项
Google Play 官方支持 APK 格式文件更新 AAB 格式文件，必须替换 Google Play 自生成签名文件，替换签名后需发布新版本。
更新 AAB 文件
新建项目更新 AAB 可使用 Google Play 自生成签名，亦可以使用自签名覆盖 Google Play 签名 (Google 推荐使用 Google Play 生成签名)。
现有 APK 更新 AAB 使用现有 APK 上传签名文件生成对应签名文件，上传到覆盖 Google Play 自生成签名。
更新 Google Play 签名文件
新建项目更新 Google Play 签名文件
进入 Google Play 控制台。
选择 测试 > 内部测试。
在 应用完整性 部分，点击 更改应用签名密匙。
在 更改应用签名密匙 对话框，点击 使用其他密匙。
选择 Export and upload a key from Java keystore 并根据页面指令上传签名文件。
已发布应用更新 Google Play 签名文件
进入 Google Play 控制台。
选择 设置 > 应用完整性。
在 Upgrade your app signing key for new installs 部分，点击 请求升级密匙。
选择 我需要针对多个版本应用或此应用的预安装版本使用同一密匙 > 上传新的应用签名密匙，并根据页面指令上传签名文件。
适配方案
总大小 150MB 或以下的 App:只需要在打包时选择打 bundle 包即可，其他无需改动。由于 APK Expansion File(OBB) 和 Android App Bundle 不兼容，所以如果之前已经用了 OBB，则参考 2。
有 OBB 文件，且大小主要是集中在资源文件上的 app：根据 Asset Library 文档，新建 module 用来存放之前放在 OBB 文件里的资源。最好是对资源做好分类，分 module 做成不同的 Asset Pack 按需加载。
install-time: 下载 app 时一并下载，app 装完，这个 Asset Pack 也已经可用。
fast-follow：app 安装后，紧跟着 Google Play 会继续下载 fast-follow 类型的 Asset Pack，所以使用时不保证可用，需要先检查状态。
on-demand：仅在需要时由 app 自行下载。
较大型的 app: 参考 Asset Library 文档，Feature Library 文档，对工程不同模块进行划分，根据模块使用情况选择来加载。
install-time: 下载 app 时一并下载，app 装完，这个 Feature Module 也已经可用。
on-demand: 仅在需要时由 app 自行下载。
conditional: 根据条件在 app 下载时一并下载，通常用于设备满足某种硬件/软件条件时触发。例如设备分辨率，系统 API 版本，OpenGL 版本等等。
Legacy Support：API level <= 19 (Android 4.4) 虽然不支持分包方式安装，但 Google Play 会做好处理。Google Play 依然会生成较为精简的 APK，不过滤语言，但会过滤分辨率和 CPU 架构的 APK 给用户下载。需要注意的是，如果有模块是配了 on-demand 方式加载的，需要评估是否把这个模块也要合进来，如果需要，则要把 fusing 的配置设置为 enable。
配合业务适配
需要保证 Player Network SDK 的模块都必须在主模块或者在 install-time 模块里。
另外需要注意 Feature Module 的依赖。假设业务方选择将 INTLCore 放在 Feature A，INTLFacebook 放在 Feature B，则调用 Feature B 之前必须保证 Feature A 已经加载，否则会因为找不到对应代码或资源崩溃。