Google Play 上架全流程

Google Play 上架全流程：开发者账号注册、应用创建、AAB 上传、商店列表（标题/截图/描述/分类）、内容分级问卷、隐私政策、内测→封闭→开放→正式发布轨道、分阶段发布。

学习目标

• 掌握 Google Play 开发者账号注册与应用创建流程；
• 能够上传 AAB 并配置商店列表与内容分级；
• 理解隐私政策与数据安全声明的填写要求；
• 熟悉内测/封闭测试/开放测试/正式发布四个轨道；
• 掌握分阶段发布（staged rollout）灰度策略。

Google Play 上架全流程

第 37 章我们打好了签名 AAB。本章把这个 AAB 推上 Google Play，让真实用户能下载到。整个流程从前置准备到正式发布约 7 个步骤：

账号注册 → 创建应用 → 上传 AAB → 商店列表 → 内容分级 → 隐私政策 → 轨道发布

本章内容主体是流程说明 + 控制台操作步骤，截图位置用文字描述（实际操作时以 Play Console 当前界面为准，Google 会迭代 UI）。

一、开发者账号注册

1. 账号类型

Google Play 开发者账号分两种：

• 个人账号（Personal）：用个人 Gmail 注册，一次性 $25 注册费，账号名显示个人姓名；
• 组织账号（Organization）：需提供组织 D-U-N-S 编号、营业执照、法人身份验证，注册费相同，商店显示组织名（更专业，企业应用必选）。

2023 年起 Google 对个人账号新注册要求“20 人内测员锁定 14 天”才能上架首次正式版，组织账号无此限制，建议公司直接走组织账号。

2. 注册步骤

1. 准备一个 Google 账号（建议企业邮箱绑定，便于后续交接）；
2. 访问 Play Console 用该账号登录；
3. 选择账号类型（个人/组织）；
4. 填写开发者名称（将展示在 Play 商店，确认后不可随意改）、联系方式；
5. 组织账号额外提交：法律实体名称、D-U-N-S 编号（可在 dnb.com 申请）、官网域名邮箱验证；
6. 支付 $25 一次性注册费（仅支持信用卡/借记卡，国内卡可用）；
7. 审核通过（个人通常 1-3 天，组织 3-7 天，需人工复核）。

D-U-N-S 编号申请免费但需 1-2 周，企业提前规划。

二、创建应用

1. 新建应用

进入 Play Console，点击 「所有应用 → 创建应用」：

• 应用名称：用户在商店看到的名字（可后续修改，但与已注册商标冲突会被拒）；
• 默认语言：商店列表的默认语言；
• 应用类型：应用（Application）或游戏（Game）；
• 付费/免费：是否收费，定后付费版需提交分销协议。

2. 应用基本信息

进入应用详情，「设置 → 商店设置」 填写：

• 应用包名（com.example.app，与 AAB 内一致，定后不可改）；
• 应用名称、简短描述、完整描述；
• 默认语言与多语言商店列表；
• 应用图标（512×512 PNG，不带 alpha）；
• 置顶大图（1024×500 PNG/JPG）；
• 应用类别（工具/社交/教育等）；
• 联系邮箱（用户反馈）。

三、上传 AAB（App Bundle）

1. 进入发布轨道

Play 提供 4 个发布轨道（Track）：

内部测试 → 封闭测试 → 开放测试 → 正式发布
   ↑               ↑          ↑          ↑
 最多 100 人    邀请链接      Google Play  全员
 内部测试员     邮件名单      商店可见

2. 上传步骤

1. 选择某个轨道（如正式发布 → 「创建新版本」）；
2. Google Play 应用签名：
   • 首次上传时 Play 会问是否启用 Play App Signing，强烈建议启用——把应用签名密钥托管给 Google，后续 Play 用它签最终下发给用户的包；
   • 你上传的 AAB 用你的“上传密钥”签，Play 用应用签名密钥重新签最终包。即便上传密钥丢失，仍可申请重置。
3. 上传 AAB：拖入 app-release.aab 文件，Play 会自动校验包名、版本号、签名方案；
4. 填写版本说明（Release notes）：用户看到的“本次更新内容”，多语言可分别填；
5. 版本发布阶段（仅正式轨道可见）：选择立即发布或定时发布；
6. 提交审核。

上传的 AAB 内 versionCode 必须大于上一个已发布的版本，否则 Play 拒绝。

3. 上传被拒的常见原因

• versionCode 没递增（用 git commit hash 当 versionCode 必踩坑）；
• 包名与已存在应用冲突（同包名不能再注册第二个账号）；
• 签名方案不全（缺少 V2/V3）；
• AAB 内 base 模块缺启动 Activity；
• targetSdk 低于 Play 当前最低要求（2026 年要求新应用 targetSdk 34+）；
• 权限声明与实际不符（如声明了相机权限但代码里没用，会被人工审核退回）。

四、商店列表（Store Listing）

商店列表是用户在 Play 看到的应用详情页。Play Console 里 「主要商品详情」 必填项：

1. 文字内容

最佳实践：

• 应用名称前 2-3 个词放关键词（如“记账 - 极简个人理财”），但避免堆砌；
• 简短描述突出 1 个核心卖点 + 1 个数字（“30 秒记账，省下你 1 小时”）；
• 完整描述用 emoji + 分段标题 + 列表，提升可读性，关键词密度控制在 3-5%；
• 多语言版本要人工翻译，不要机翻——机翻易触发“低质内容”降权。

2. 视觉素材

截图建议：

• 真机截图 + 简洁文案叠加（如左图右字），而非纯 UI 截屏；
• 前 3 张最关键——列表页只显示前 3 张；
• 海外版做英文版，国内市场再换中文；
• 用 Figma/Photoshop 模板批量出图，统一品牌感。

3. 应用分类

• 类别：从 30+ 类目中选最贴近的（如“工具”、“财务”、“社交”）；
• 内容分级：需填问卷（见下面内容分级）；
• 标签：可选最多 5 个标签（如“健身”、“理财”），帮助算法匹配；
• 是否含广告：勾选后会被标“内含广告”，影响转化率。

五、内容分级

Google Play 不允许开发者自评分，必须填 IARC（国际年龄分级联盟）问卷，系统根据答案自动给出全球分级：

• ESRB（北美）：E / T / M / AO；
• PEGI（欧洲）：3 / 7 / 12 / 16 / 18；
• USK（德国）；
• ClassInd（巴西）；
• GRAC（韩国）。

问卷要点

进入 「应用完整性 → 应用内容 → 目标受众」 与 「内容分级」 填写问卷，常见问题：

• 是否含暴力内容（卡通/真实/血腥）；
• 是否含色情或裸露；
• 是否含在线赌博（涉及真钱）；
• 是否共享用户位置数据；
• 是否允许用户互动（UGC）；
• 是否含未过滤 UGC。

关键陷阱：

• 勾选“允许用户生成内容但无审核机制”会直接判 18+；
• 涉及“位置数据共享给第三方”会触发数据安全额外审查；
• 填了“无暴力”，实际有战斗画面，被举报会下架整改。

六、隐私政策与数据安全

1. 隐私政策（强制）

Google Play 要求所有应用必须提供可访问的隐私政策 URL，不论是否收集数据。

隐私政策必须包含：

• 收集哪些数据（设备 ID、位置、通讯录等）；
• 数据用途（分析、广告、推送）；
• 是否分享给第三方（及其身份）；
• 数据保留期限；
• 用户权利（访问、删除、撤回同意）；
• 儿童隐私（COPPA / GDPR-K 合规）；
• 联系方式。

把隐私政策托管到自家域名（如 https://example.com/privacy），URL 不可改成 404。

2. 数据安全表单

进入 「应用完整性 → 应用内容 → 数据安全」，逐项声明：

• 是否收集数据；
• 每类数据（大致：位置、个人信息、财务、健康、通讯、文件、搜索历史、ID 等）；
• 是否加密传输；
• 是否允许用户请求删除数据。

声明与实际行为不符会被人工审核退回，第三方 SDK（如 Firebase、广告 SDK）收集的数据也要声明——很多下架事故源于“SDK 偷偷收集但开发者没声明”。

工具：用 AppBingo Privacy Policy Generator 自动生成模板。

3. 其他强制声明

• 政府应用：政府/公共服务应用需额外验证；
• 金融应用：金融相关应用（贷款、支付）需提交资质；
• 儿童应用：选“目标受众含儿童”会触发更严苛的 COPPA 审查；
• 广告 ID：用了广告 ID 需声明用途（2026 年起 Google 强制要求声明，否则下架）。

七、发布轨道与分阶段发布

1. 测试轨道渐进

新应用推荐流程：

1. 内部测试：团队 + PM 自测，确认包能装、能跑；
2. 封闭测试：发给公司外部 alpha 用户（邀请链接，约 50-200 人）；
3. 开放测试：在 Play 商店公开招募 beta 用户；
4. 正式发布：全员可见。

每个轨道升级前都建议至少稳定 3-7 天，看 Crashlytics（第 40 章）崩溃率不上升。

2. 封闭测试邀请

封闭测试有两种邀请方式：

• 邮件名单（Email list）：Play Console 添加 Gmail 邮箱，最多 2000 个；用户搜到应用后看到“加入测试”按钮；
• 邀请链接：生成一个 https://play.google.com/apps/testing/包名 链接，分享给任意用户，点击即可加入。

2023 年起新个人账号首次正式发布前，必须先完成“20 人 14 天封闭测试”，否则无法提交正式版。

3. 分阶段发布（Staged Rollout）

正式轨道支持“灰度”，按比例逐步放量：

• 第一次发布：选 10% 用户；
• 观察 1-3 天 Crashlytics 崩溃率与负评；
• 稳定后逐步放量：10% → 25% → 50% → 100%；
• 出问题可“暂停”发布，紧急情况用“回滚”恢复上一版本（但 Play 不支持二进制回滚，需重新提交旧版本 AAB）。

在 「正式发布 → 创建新版本」 底部勾选 「分阶段发布」 并填百分比。

4. 紧急回滚

线上严重 bug（启动崩溃、支付中断）需快速恢复：

1. Play Console 「正式发布」 → 找到当前版本 → 点 「暂停发布」（新用户不再下载）；
2. 找到上一个稳定版本 → 点 「恢复发布」（已暂停的旧版本重新对新用户可见）；
3. 提交修复版 AAB → 走分阶段发布小流量验证。

注意：已升级到新版的用户无法回退（除非卸载重装），所以分阶段发布早期发现问题是关键。

八、上架后的合规审查

Google Play 会定期扫描已上架应用，常见的下架/警告原因：

• SDK 收集数据未声明：广告/分析 SDK 升级后开始收集新数据，开发者没更新数据安全表单；
• targetSdk 过低：每年 Google 提升最低要求，新应用须 targetSdk 34+，存量应用也要跟进，否则新用户无法下载；
• 后台定位/通话录音：需声明并人工审核，普通权限申请会被拒；
• Notarial family policy：家庭成员共享时是否可见；
• 死亡用户数据：要求提供数据删除 API，用户请求删除时 30 天内执行。

定期查看 Play Console 的 「政策与计划」 通知，及时响应。

常见坑与最佳实践

1. 没做 Play App Signing：上传密钥丢失后无法更新应用。首次上传时务必启用，由 Google 托管应用签名密钥。
2. 商店列表翻译用机翻：被算法识别为低质内容，搜索排名下降。多语言版本请人工翻译或专业本地化。
3. 截图随便截屏：纯 UI 截图转化率比带文案的差 30%+。用 Figma 模板做“截图 + 文字 + 装饰”组合图。
4. 数据安全表单漏声明 SDK：第三方 SDK（如 Firebase、Bugly、广告 SDK）收集的数据也要声明，否则人工审核退回甚至下架。
5. 首次发布直接 100%：没有灰度缓冲，崩溃影响全员。正式轨道必走 staged rollout，10% 起步观察 3 天。
6. 回滚不知道怎么操作：Play 不支持二进制回滚，而是“暂停当前 + 恢复旧版本”，提前在 Runbook 文档化操作步骤。
7. 隐私政策 URL 失效：换域名后忘了更新 Play Console 里的 URL，导致“应用违反政策”下架。把隐私政策托管到稳定域名。
8. 版本号 versionCode 不递增：上传被拒。CI 里用 git rev-list --count HEAD 自动生成递增整数作 versionCode，避免冲突。
9. 测试轨道跳过：没做封闭测试直接上正式版，首次崩溃率 5%+。每个轨道至少稳定 3 天再升。
10. 没看 Play Console 政策通知：政策违规邮件 7 天不响应会被自动下架。把 Play Console 通知转发到团队邮箱 + 钉钉/飞书机器人。

章节小结

本章走完了 Google Play 上架全流程：

• 账号：个人 vs 组织，组织走 D-U-N-S 验证，一次性 $25 注册费；
• 应用创建：包名定后不可改，类型/付费/默认语言在创建时确定；
• AAB 上传：启用 Play App Signing，AAB 内 versionCode 必须递增，V1/V2/V3 签名方案齐全；
• 商店列表：名称/描述/截图/图标/置顶图，截图前 3 张最关键；
• 内容分级：填 IARC 问卷，UGC/赌博/色情会判 18+；
• 隐私政策 + 数据安全：第三方 SDK 收集的数据也要声明；
• 轨道发布：内部测试 → 封闭测试 → 开放测试 → 正式发布，分阶段发布从 10% 起步逐步放量，问题早期发现可暂停。

下一章预告

应用上架后，版本迭代与灰度更新是日常运维。第 39 章将讲解版本号策略（versionCode/versionName）、Google Play staged rollout 灰度发布、In-App Update API（应用内更新）以及强制更新策略。