以前我在想，aab 明明可以设计成像民间 xapk 那样，一个 zip 包里面一个清单再加一组已经由 deployment key 签名的 split apk ，这样商店根据目标机器的情况挑选一组 apk 下发就行，不需要重新签名，但现在：
- aab 需要一个单独的 upload key 来签名，这玩意除了让 GP 验证打包上传者是否控制 upload key 之外没任何意义，因为得先登开发者账号才能上传 aab ，都不知道这个重复验证有何意义
- 从 aab 生成 apk 需要 deployment key 重新签名，所以也没法通过验证 aab 签名来确定是否是同一来源
- 为了“证明”GP 自己在重签名是没篡改，还煞有介事的在 apksigner 搞了个 code transparency 签名，但分发和最终用户都不会管这玩意，都不知道谁会用
- 清单和签名用的格式五花八门，aab 的清单(BundleConfig.pb)是 protobuf ，签名继续用 jar sign ，元数据有 plaintext 有 json ，code transparency 签名是 JWT ，apk 里继续用非标 binary xml
- 由于需要重签名，所以商店必须托管 deployment key ，等于强制加入 Play Signing 计划，所有使用 aab 的商店都需要托管 deployment key ，增加了泄漏风险，也丧失了通过签名验证来源的有效性
- 因为需要支持运行时按需加载，强制依赖专有的 Play Core 库，受此限制等于强制淘汰 5.1 以下的系统（虽然影响是很小），而且因为调用商店并非 Android 公有 API ，包含 play core 的包一般不能用于第三方渠道，
- 因为 aab 不流通，所以 AOSP 的包安装器只有 API 支持但没有 UI 功能支持，个别厂商甚至拒绝修复 API 实现缺陷
我感觉 aab 这玩意把流程设计成这样子是跟 App Store 学的，从开发测试到分发整一堆不知道要防谁验证谁的签名，还跟最终用户部署没关系，现在 aab 流程最多搞出了三套证书，我是不是还得谢谷隆恩没把 mobileprovision 审批公文和推送证书整出来？
2
Select Language