Google Play target API 要求

截至 2026 年 3 月 22 日，Google 当前帮助中心页面写明的关键节点仍是 2025 年 8 月 31 日和 2025 年 11 月 1 日。很多团队只记住“要升 targetSdkVersion”，但没意识到这会分别影响新包提交、更新包提交和老包对新用户的可见性。

Google 当前规则是：自 2025 年 8 月 31 日起，新 App 和 App updates 需要 target Android 15，也就是 API level 35；Wear OS、Android TV、Android Automotive OS 则需要 target Android 14，也就是 API level 34。

对 existing apps 来说，影响不只是“以后不能更新”。Google 当前帮助文档还写明，若 existing app 到期时 target 低于 Android 14，运行更新 Android OS 的新设备用户将无法再发现和下载你的 App。

所以 target API 在 Google Play 里既是技术要求，也是流量和分发要求。

先把配置链路和发布时间点排清楚

处理「Google Play target API 要求」时，最容易被低估的往往不是规则本身，而是这个环节会不会直接拖慢后面的资料整理、提审沟通和版本推进。版本号、构建号、地区范围、发布窗口、测试轨道、签名、下架与转移这些问题，表面上像后台配置，实际上决定的是你的版本会不会在正确时间、正确地区、以正确状态出现在用户面前。

这类文章之所以容易写得空，是因为很多人只记操作步骤，却没说明配置之间的先后依赖。结果常见问题就变成：包已上传但地区没开、审核通过了却没放量、版本切换了却忘了同步旧配置。

更稳的处理方式，是先把“谁决定发布时间、谁控制配置、谁负责最终核对”这条链路理顺，再回头看按钮和字段。配置类问题真正难的从来不是点哪里，而是多个开关要在同一轮对齐。

新包、更新包、老包分别受什么影响

先把三种情况拆开看，判断才不会混乱。

Google 当前帮助文档写明：新 App 和 App updates 都必须在 2025 年 8 月 31 日起满足 API 35；而 existing app 如果仍低于 Android 14，则会对运行更高 Android 版本的新用户失去 discoverability。已发布旧包不是立刻全量下架，而是先丢掉一部分新用户入口。

这也是为什么有些项目“后台还能看到 App，但自然下载突然掉很多”，问题可能不是关键词，而是 target API 已经过线了。

延期窗口怎么理解

Google 当前页面仍提到一个延期节点。

帮助中心写的是：如果你需要更多时间更新，可申请延期到 2025 年 11 月 1 日。对应表单会在 Play Console 里向受影响 App 提供，不是所有账号都会默认看到。

所以如果你的 App 已收到 policy warnings 或 Inbox message，不要只在代码层面排期，也要同步盯 Play Console 里的表单和提示，避免错过可申请的缓冲期。

哪些 App 可能不受这条规则影响

Google 官方也列了例外，但范围没有很多团队想得那么宽。

当前帮助文档写明的典型例外是 permanently private apps，也就是只面向特定组织、用于内部发布的永久私有应用。普通公开分发 App 不在这个豁免范围里。

所以只要你的 App 还在面向公开市场，不要把“我们用户量小”或“我们只做垂类”当成豁免理由。

对业务最现实的影响是什么

对多数团队来说，最痛的不是升级工作量，而是流量断层。

Google 当前帮助文档说明，已经安装过 App 的用户通常不受影响，仍可以发现、重新安装和继续使用；真正受影响的是运行更高 Android 版本的新用户，他们可能根本看不到你的 App 页面或无法下载。

换句话说，target API 不达标时，你不是“今天就没用户”，而是“新增长在持续变差”。这比显性的拒包更容易被忽视。

应对顺序怎么排

最稳的顺序是先确认 Play 规则，再安排代码和提审。

建议先确认当前线上版本和待发版本的 targetSdkVersion；再看 Play Console 是否已有 warning 或延期入口；然后评估第三方 SDK、权限声明和敏感功能是否会随 API 升级触发新合规问题，最后再走提交流程。不要把 target API 当成纯 gradle 参数升级。

发布类问题常常输在最后一公里

很多项目不是卡在提交，而是卡在通过之后没人做最后一轮确认：是否自动放量、旧版本是否仍会影响用户、测试入口是否还在、目标地区是否同步生效。

这也是为什么配置类文章不能只讲“如何设置”，还要讲“设置完以后谁来复核”。只要上线后的动作没被写进流程，团队就会一遍遍把问题误判成平台异常。

把发布时间、地区、包体版本和后续放量动作串到同一个检查顺序里，文章的价值才不只是教程，而是真能减少发版事故。

FAQ

Q：新包和更新包现在要多少 API？
A：截至 2026 年 3 月 22 日，Google 当前帮助中心写的是 2025 年 8 月 31 日后需达到 Android 15，也就是 API 35。

Q：老包不升级会立刻彻底下架吗？
A：不一定。Google 当前说明是会先对运行更高 Android 版本的新用户失去可见性。

Q：已经安装 App 的老用户会受影响吗？
A：Google 当前帮助文档说明，已安装用户通常仍可继续发现、重装和使用 App。

Q：还有延期机会吗？
A：官方当前页面仍写有可申请延期到 2025 年 11 月 1 日，但入口需以 Play Console 对受影响 App 的实际提示为准。

延伸阅读：审核慢排查、敏感权限声明、广告与 SDK 合规。

把这个环节放回谷歌上架主流程里看

「Google Play target API 要求」处理的是谷歌上架里的一个具体节点。若你还在梳理整体节奏，先回到 Google Play 上架指南 看总流程，再根据当前阶段补齐资料，会比只盯着单点问题更容易把整条线理顺。

如果你们准备让外部团队统一执行资料整理、送审和后续回复，也可以直接对照 Google Play 代上架服务 的交接方式，提前把责任位和资料边界整理出来。