Google Play 发版链路全面重构：合规前置、审核自动化、生态全面收紧

近日，Google 发布了一篇面向 Android 和 Google Play 发布链路的更新说明。它把政策检查、SDK 合规、风控、预审、发布状态 API、并行审核、开发者验证放到了一条链路里。

政策问题前移到写代码阶段

过去很多 Play 审核问题，都是发版前才暴露。

比如登录凭证没填、照片权限申请理由不充分、Data safety 表单和实际行为不一致、SDK 版本不符合政策要求。

Google 这次提到，Play Policy Insights 会继续扩展到 Android Studio 里。开发者写代码时就能看到常见政策风险提醒，比如缺少登录凭证。

今年晚些时候，如果把 Play developer account 直接连接到 Android Studio，还会拿到更贴合当前应用的提示。

这意味着政策检查不再只属于运营同学和发版同学。

权限、SDK、登录态、用户数据流向，这些代码层面的东西会更早出现在 IDE 里。

团队里如果有公共组件、基础 SDK、账号模块、相册模块、定位模块，最好把这类提示当成开发阶段的问题，而不是提审阶段的问题。

SDK Index 会进入开发流程

Google 还提到，会把 SDK insights 直接带到开发流程里，让开发者更快看到 SDK 是否符合 Play policies。

这对 Android 项目影响很直接。

很多应用的政策风险并不来自业务代码，而来自第三方 SDK。

广告 SDK、统计 SDK、归因 SDK、登录 SDK、推送 SDK、地图 SDK，只要它们收集用户数据、使用敏感权限、动态加载代码或更新策略不透明，都可能影响应用审核。

以前团队常见做法是：发版前整理依赖列表，人工检查 SDK 版本和隐私说明。

后面更合理的做法应该是把 SDK 检查放进依赖升级流程：

bash 复制代码

新增 SDK
  -> 查看 SDK Index / Play policy 状态
  -> 确认数据收集和权限使用
  -> 更新隐私政策和 Data safety
  -> 再进入版本分支

这不是多一道流程。

SDK 一旦进入主干，后面再移除通常很麻烦。埋点、广告、登录、推送这类 SDK 往往会穿透多个模块。

越早发现合规风险，成本越低。

Play Integrity 更适合放进关键路径

Google 这次也提到 Play Integrity API 的 warm-up latency 明显缩短。

这句话对业务团队更有用。

以前实时风控检查如果太慢，就不适合放在登录、支付、领券、提现、账号绑定这类链路里。延迟一高，用户体验会先出问题。

如果 warm-up 变短，Play Integrity 就更适合参与速度敏感的业务判断。

比如登录时检查设备和应用完整性，支付前判断请求环境是否异常，活动领取前识别高风险交互。

代码层一般不要把 Integrity 结果直接写死成"通过/拒绝"。

更稳的是把结果交给服务端风控策略：

bash 复制代码

data class IntegrityRiskSignal(
    val requestHash: String,
    val packageName: String,
    val verdictToken: String,
)

suspend fun submitIntegritySignal(signal: IntegrityRiskSignal): RiskDecision {
    return riskApi.evaluate(signal)
}

客户端负责拿信号，服务端负责结合账号、设备、订单、地区、历史行为做最终决策。

这样策略变化不需要重新发版。

预审会拦更多常见问题

Google Play 已经有 pre-review checks，这次提到它会继续扩展，能在提交前识别不必要的照片权限申请和其他常见违规。

这对 Android 17 之后的权限治理很有现实意义。

相册、位置、联系人这类权限，平台已经给了更细的系统能力。Google 也在文章里提到 contact picker 和 location button 这类更容易集成的隐私工具。

也就是说，如果一个业务只是让用户选一张头像，却申请整库照片权限；只是让用户选择一个联系人，却申请通讯录读取权限；只是需要一次位置确认，却长期持有后台定位权限，后续都更容易在发版前被拦出来。

权限申请可以按这个顺序改：

bash 复制代码

能用系统选择器，不申请整库权限
能用一次性授权，不申请长期权限
能用前台权限，不申请后台权限
能按场景解释，不写泛泛而谈的权限说明

这类改动不只是为了过审。

权限越少，用户信任成本越低，安全团队和法务同学后续要维护的说明也越少。

发布状态 API 进入自动化链路

发版团队更应该看的是 release status API。

Google 提到，新 API 可以检查 release 是否已经 approved 和 published。

这会影响 CI/CD。

很多团队现在的发布链路是：上传 AAB、提交审核、人工去 Play Console 看状态、在群里同步"还在 review""已经通过""等灰度"。

如果 release status 能进入自动化流程，发布机器人就可以持续轮询状态，并把变化同步到内部系统。

示例可以整理成这样：

bash 复制代码

curl -H "Authorization: Bearer $TOKEN" \
  "https://androidpublisher.googleapis.com/androidpublisher/v3/applications/com.example.app/tracks/production/releases"

拿到状态后，内部发布平台可以做三件事：

• 审核中：锁定当前 release，禁止重复提交
• 已通过：通知负责人进入灰度或 managed publishing
• 已发布：补齐发布记录，关闭版本任务

Google 还提到一个容易被忽略的点：当 review 已经在进行时，可以阻止新的 commit，避免无意中重启排队位置。

API 层可以把这个约束写进提交逻辑：

bash 复制代码

curl -X POST \
  -H "Authorization: Bearer $TOKEN" \
  "https://androidpublisher.googleapis.com/androidpublisher/v3/applications/com.example.app/edits/$EDIT_ID:commit?changesNotSentForReview=true"

真实项目里参数名和行为要按当前 Google Play Developer API 文档校验。重点是发布平台要有"审核中不要乱提交"的保护，而不是靠人记住。

测试轨道不会再互相卡住

Google 还提到，今年晚些时候会调整 review architecture，支持 parallel publishing，并让测试轨道审核更快。

关键变化是：closed、open、production tracks 会被隔离。一个 track 的 review 不应该再阻塞另一个 track 的更新。

这对有多条发布线的团队很关键。

比如 production 正在审核一个合规改动，closed testing 又要发一个紧急验证包。现在很多团队会担心互相影响，只能等前一个流程结束。

如果轨道之间能并行，发布策略可以更清楚：

• internal testing：验证构建和基础冒烟
• closed testing：给 QA、运营、灰度用户验证功能
• open testing：扩大验证范围
• production：正式发布和 staged rollout

不要把所有风险都压到 production。

测试轨道审核更快之后，功能验证、政策检查和正式发布可以拆开走。

开发者验证会扩到整个 Android 生态

最后一个变化是 developer verification。

Google 表示，从 9 月开始，会先在部分国家推出相关保护，把开发者验证带到整个 Android 生态。

这件事不只影响 Play Store。

它的目标是让恶意开发者更难反复换身份分发有害应用，同时尽量不改变大多数用户的安装体验。

对正常团队来说，影响主要在账号治理。

公司主体、开发者账号、签名密钥、应用包名、Play App Signing、账号转移，都要有清楚的归属和交接记录。

Google 这次还提到 Play App Signing 会在今年支持 post-quantum cryptography，用来提前应对量子计算带来的潜在签名安全风险。

这不是今天就要改业务代码，但说明应用签名、开发者身份和分发安全会继续变严。

账号和签名如果还靠个人电脑、个人邮箱、临时共享文档管理，后面会越来越难维护。

写在最后

Google Play 的发布链路正在从"提交后审核"变成"开发时提示、提交前预检、审核中可观测、轨道间并行、生态侧验证"。

对 Android 团队来说，发版不再只是上传 AAB。

IDE、SDK、权限、风控、CI/CD、Play Console、账号主体都会进入同一条发布链路。

#Android #GooglePlay #AndroidStudio #应用安全 #应用发布