Google Play 发布：AAB、测试轨道、Data Safety 与分阶段发布
系统讲清安卓海外主渠道 Google Play 的发布工程：开发者账号、AAB 与 Play 应用签名、四级测试轨道、商品详情与数据安全表单、内容分级与目标受众、政策合规，以及正式版的分阶段发布与紧急暂停
- 理解 Google Play 为什么用 AAB、Play 应用签名托管是怎么回事
- 分清内部测试、封闭测试、开放测试、正式四个轨道的用途与顺序
- 知道商品详情、内容分级、目标受众、Data Safety 表单要准备什么
- 掌握分阶段发布、紧急暂停与版本回退的操作策略
海外安卓：主战场是 Google Play
在大多数海外市场，安卓分发高度集中在 Google Play，流程比国内多渠道统一得多，但它有一套自己的发布机制和严格政策。注册 Google Play Console 开发者账号需一次性费用（金额以官方为准），并完成身份验证。这一课走通从包到上架的完整技术流程，政策细则以 Google Play 官方最新文档为准。
AAB 与 Play 应用签名
Google Play 要求上传 AAB（Android App Bundle，见 Stage15-m8）而不是 APK。关键机制是 Play App Signing：你上传用「上传密钥」签名的 AAB，Google 保管真正的「应用签名密钥」，并针对每个用户的设备生成、签名并下发优化后的 APK。好处是密钥被 Google 托管不易丢、用户下载体积更小；你要妥善保管的是上传密钥，并理解最终分发给用户的签名密钥在 Google 侧。
Google Play 产物与签名链路
本地用上传密钥签名 AAB -> 上传 Play Console
-> Google 用托管的应用签名密钥，按设备生成优化 APK 下发用户
好处：体积更小(按需拆分 ABI/密度/语言)、签名密钥云端托管防丢
注意：一旦启用 Play 应用签名，分发签名由 Google 管理（不可逆，需知悉）四级发布轨道：先测后发，逐级放大
Google Play 最有价值的设计是测试轨道，让你在正式面向公众前，用真实分发链路小范围验证：
推荐路径：内部测试确认包能装、核心流程通 → 封闭测试邀请种子用户、收集崩溃与反馈 →（需要时）开放测试扩大样本 → 确认稳定再推正式。测试轨道走的是和正式一样的签名、分发、内购沙盒机制，能提前暴露大量问题。
上架前要填的「非代码」内容（技术相关部分）
Play Console 创建发布需要准备
□ 商品详情：标题、简短/完整描述、图标、特色图、手机截图(可多语言)
□ 内容分级问卷：如实填写，生成官方分级，乱填可能下架
□ 目标受众与内容：年龄段、是否面向儿童(家庭政策更严)
□ 数据安全 Data Safety：声明收集了哪些数据、用途、是否共享、是否可删
—— 必须与 App 实际行为一致(技术上要先盘点 SDK 到底采集什么)
□ 权限声明：敏感权限(如后台定位)需说明用途并可能要填声明表单
□ 目标 API 级别：满足 Google 对 targetSdk 的最低要求(逐年提高，以官方为准)
□ 隐私政策链接：公网可访问的 HTTPS 隐私政策Data Safety 表单不是「随便填填」：Google 会核查，第三方 SDK 采集的数据也要算进去（很多驳回源于集成了某个统计/广告 SDK 却没在表单声明）。技术做法是在发布前做一次「数据收集盘点」：列出 App 和每个 SDK 采集的数据类型、用途、是否传输、用户能否删除，再据此填写。这与 Stage16-m5 的数据映射表是同一份工作。
正式发布：分阶段放量与紧急暂停
正式版支持 Staged Rollout（分阶段发布）：先放给一定百分比用户，观察崩溃率与差评，无异常再逐步提到 100%。一旦发现严重问题，可以立即 Halt（暂停）停止继续放量——注意暂停能阻止更多人拿到坏版本，但已经装上的用户不会自动回退，真正修复仍需发一个更高 versionCode 的新版本。这就是为什么线上严重 bug 的正确姿势是「暂停放量 + 尽快发修复版」，而不是指望撤销。
Google Play 常见驳回与政策红线（选学）
权限滥用：申请与功能无关的敏感权限、用替代手段也能实现却要高风险权限；目标 API 级别过低；数据安全声明与实际不符、缺隐私政策；支付违规：数字商品没用 Play Billing 而引导外部支付；内容与元数据：描述/截图误导、关键词堆砌、知识产权问题；WebView 套壳被认为缺乏功能性。提审前对照官方政策中心逐项自查，驳回后按邮件指出的具体政策条目修复再申诉/重提。
在 Google Play 正式发布后发现新版本有严重崩溃，最正确的处置组合是？
本节小结
Google Play 需Console账号、上传AAB并用Play App Signing托管应用签名密钥(本地用上传密钥、Google按设备生成优化APK)。四级轨道：内部测试(秒级自测)→封闭测试(定向邀请)→开放测试(公开公测)→正式生产，走与正式一致的签名分发内购链路提前暴露问题。上架准备商品详情、内容分级问卷、目标受众、Data Safety数据安全声明(必须与App及第三方SDK真实采集一致，发布前做数据收集盘点)、敏感权限声明、targetSdk最低要求、HTTPS隐私政策。正式用Staged Rollout百分比分阶段放量观察崩溃差评，严重问题Halt暂停阻止扩散+发更高versionCode修复版(已装用户不会自动回退、版本号不可倒退)。常见驳回：权限滥用/targetSdk过低/数据声明不符/数字商品未用Play Billing/元数据误导/套壳。
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
versionName 是给用户看的版本名，versionCode（构建号）只能单调递增、绝不回退，构建时间要和服务端升级清单一致。线上包、归档包、OTA 包必须用同一签名，并把文件大小和哈希（如 MD5/SHA）写进服务端元数据；客户端下载完成先校验哈希再安装，能从根上杜绝「下到一半的坏包被安装」。每次发版把这几项列成清单逐项核对。