以前我在想，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 审批公文和推送证书整出来？

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/9/21 22:58:39