AAB 导出上架 Google Play：签名在设备上完成
为什么导出 AAB
Google Play 从 2021 年开始要求新应用必须提交 App Bundle（AAB）格式，而不是传统的 APK。AAB 相比 APK 的好处：
- 动态分发：Play Store 根据用户设备架构、屏幕尺寸、语言等生成最精简的 APK 变体
- 更小下载体积：用户只下载需要的资源（比如 arm64-v8a 用户不会下载 armeabi-v7a 的原生库）
- 更好的覆盖率：单个 AAB 覆盖所有设备变体
WebToApp 的 AAB 导出
WebToApp 的构建对话框里可以直接选择「导出 AAB」。签名流程和导出 APK 完全相同：V1/V2/V3 方案，证书在设备上完成签名。
上架流程
- 在 Google Play Console 创建开发者账号（一次性注册费 25 美元）
- 创建一个新应用
- 在 WebToApp 里构建应用，选择导出 AAB
- 把 AAB 文件上传到 Play Console 的「生产」或「内部测试」轨道
- 填写商品详情、截图、分类、隐私政策等信息
- 发布
AAB 和 APK 的区别
| 维度 | APK | AAB |
|---|---|---|
| 本质 | 直接安装包 | Play Store 分发格式 |
| 能否直接安装 | ✅ | ❌ 需要 Play Store 生成 APK |
| 能否直接分享给朋友 | ✅ | ❌ 需要转换成 APK |
| 体积 | 覆盖所有设备 | 由 Play Store 按需生成 |
| Google Play 要求 | 不再接受新应用 | 强制要求 |
实用建议：需要上架就导 AAB，需要直接分发就导 APK。两种格式可以同时导出——WebToApp 的构建流程很轻量。
签名密钥的关系
上架 Google Play 有两条密钥策略：
- App Signing by Google Play（推荐）：上传你的签名密钥给 Google，Google 帮你管理。生成的 APK 变体由 Google 用相同密钥签名
- 自己管理密钥：自己保管密钥，每次提交更新用同一个密钥
WebToApp 的设备端签名两种策略都支持——不管你选哪种，构建器都用你自己的证书完成签名，然后把 AAB 交给 Play Console。
注意事项
- 包名：在 Play Console 创建应用时设置的包名必须和 WebToApp 里的配置一致。包名一旦注册就不能改
- 版本号：每次提交更新的 versionCode 必须比上一版大
- 合规检查：应用的隐私政策、权限声明等需要在 Play Console 单独配置
- 64 位支持：Google Play 要求新应用必须提供 64 位（arm64-v8a）支持