目标 API 级别年度更新（Android 16 / API 36）
2026-08-31 起新应用与更新通常须以 API 36 为目标；现有应用可见性另有门槛，可申请延期至 2026-11-01。
延期节点：2026-11-01（需符合资格并在 Console 政策状态申请）
要点速览
- 提交门槛与可见性门槛是两套规则。
- 手机常见：更新目标 36；现有应用可见性关注 35。
- Wear/TV/Auto/XR 数字不同，不能套用手机。
01
谁需要关注
- 所有计划在 8/31 后提交更新的移动应用。
- 目标 API 仍低于可见性门槛的既有应用。
- 多端形态（手表/电视/车载/XR）应用。
02
官网政策深度解读
依据 Android Developers / Play Console Help：自 2026-08-31 起，新应用与应用更新通常必须以 Android 16（API 36）或更高为目标才能提交。例外：Wear OS 与 Android Automotive OS → Android 15（API 35）+；Android TV 与 Android XR → Android 14（API 34）+。永久私有组织内部分发应用可例外。
现有应用可见性：通常须达到 Android 15（API 35）等对应门槛，才能继续向「系统版本高于应用目标 API」的新用户保持可发现/可安装；否则可能仅对系统版本不高于目标 API 的设备可见。可申请延期至 2026-11-01（表单在政策状态警告详情）。
深度解读：年更的目标不是「逼你用新 API」，而是逼生态吸收平台安全与隐私默认值。每次抬档都会激活一批行为变更：前台服务、通知、权限、后台限制等。
已安装用户通常仍可使用；伤害主要在新机用户拉新。对新机占比高的市场，可见性不达标等于增长停摆。
延期不是免费午餐：只有不合规应用会在政策状态看到入口；且 11/01 后仍要达标。把延期当缓冲，不当逃避。
03
典型场景拆解
主力 App 卡在 API 34：先冲可见性 35，再排 36 提交。
依赖过时 SDK：先做第三方矩阵，再升 targetSdk。
多端包：手表/电视单独版本火车，勿与手机混编。
04
对开发者的实际影响
赶不上 8/31：新包可能无法提交。
可见性不达标：新系统用户侧「搜得到却下不了」。
行为变更回归不足会导致崩溃与拒审双杀。
常见踩坑
- 只改 Gradle 数字，不做行为变更回归。
- Wear/TV 误用手机 API 数字。
- 以为所有人都能申请延期。
05
未来情况分析
目标 API 年更已成结构：按「永远差一年」规划技术债。
建立行为变更清单、SDK 矩阵、政策状态周检。
把 targetSdk 升级纳入季度 OKR，而不是节点突击。
落地检查清单
按序勾选，便于研发、合规与发行对齐。
- 确认各形态目标 API 数字。
- 移动应用规划 targetSdk → 36。
- 现有应用评估可见性门槛。
- 完成关键行为变更回归。
- 需要时走政策状态延期表单。
建议行动
制定分形态 targetSdk 升级计划；盯紧 Console 警告与 11/01 延期窗口。
