Build.VERSION_CODES中有哪些已废弃或不推荐使用的API级别？

Question

在 Android 开发中，`Build.VERSION_CODES` 是标识系统 API 级别的常量集合。需注意：**该枚举本身从未“废弃”任何字段**——Google 官方从未使用 `@Deprecated` 标注 `Build.VERSION_CODES` 中的任何常量（如 `ICE_CREAM_SANDWICH`, `JELLY_BEAN_MR1` 等）。但自 Android 12（API 31）起，部分低版本平台已**被官方停止支持**：Google Play 自 2023 年 8 月起强制要求新应用目标 SDK ≥ 33（Android 13），且从 2024 年 11 月起将要求 ≥ 34；同时，Android Studio 和构建工具对 API ≤ 20（Android 4.4W）的兼容性持续弱化，`targetSdkVersion` 设置为过低值（如 ≤ 22）会导致运行时权限、后台执行限制等关键行为异常。因此，虽无 `@Deprecated` 字段，但 `VERSION_CODES.JELLY_BEAN`（16）、`KITKAT`（19）、`LOLLIPOP`（21）等早期常量在现代开发中已属**事实弃用**，仅建议用于兼容性判断，绝不应作为 `targetSdkVersion` 或功能启用依据。

Answer 1

```html

一、基础认知：什么是 Build.VERSION_CODES？

Build.VERSION_CODES 是 Android SDK 提供的静态常量枚举类（实际为 public final class），用于以语义化名称映射整数型 API 级别（如 VERSION_CODES.PIE == 28）。它不是枚举类型（enum），而是编译期常量集合，自 API Level 1（Android 1.0）起持续扩展，至今已定义超 40 个常量。

关键事实：Google 从未对其中任一常量添加 @Deprecated 注解——这意味着 IDE 不会标灰、编译器不会警告、Javadoc 也不会标记“已废弃”。但这绝不等于“仍被支持”。

二、演进脉络：从兼容性工具到历史坐标

• API 16–19（Jelly Bean–KitKat）：运行时权限模型尚未引入，BroadcastReceiver 可无限制注册；后台 Service 启动无限制。
• API 21–22（Lollipop–Lollipop MR1）：Material Design 引入，但 JobIntentService 尚未替代 IntentService，后台执行限制初现端倪。
• API 23（Marshmallow）：首次引入运行时权限模型——targetSdkVersion < 23 的 App 仍走安装时授权，但系统行为已按新模型裁剪。
• API 26（Oreo）：强制后台执行限制（Background Execution Limits），startService() 在后台调用将抛出 IllegalStateException。
• API 28+（Pie+）：隐式广播白名单收缩、前台服务需声明权限、NotificationChannel 成为必选项。

三、政策驱动：平台支持生命周期的硬性断点

时间节点	政策主体	约束要求	影响范围
2023-08	Google Play	新应用 targetSdkVersion ≥ 33	API ≤ 32（Android 12L）无法上架
2024-11	Google Play	新应用 targetSdkVersion ≥ 34	API ≤ 33（Android 13）将被拒审
持续更新	Android Studio / AGP	AGP 8.3+ 已移除对 compileSdk 28- 的 lint 支持	构建时缺失新版 API 行为校验能力

四、工程实践：如何正确使用早期 VERSION_CODES 常量？

以下为反模式与正向实践对比：

// ❌ 反模式：用旧常量决定 targetSdkVersion 或功能主干逻辑
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) {
    // 启用核心功能 —— 错！JB（16）距今已超12年，该分支毫无存在必要
}

// ✅ 正模式：仅用于细粒度兼容兜底（且需有明确测试覆盖）
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
    // 使用 NotificationCompat.Builder 兜底旧通知样式
    notificationBuilder.setPriority(NotificationCompat.PRIORITY_HIGH);
} else {
    // Android 8.0+ 必须使用 NotificationChannel
    notificationBuilder.setChannelId(CHANNEL_ID);
}

五、架构视角：事实弃用（De facto Deprecation）的深层含义

“事实弃用”并非技术失效，而是生态契约失效：

• 安全契约断裂：API 19（KitKat）内核无 SELinux 完整策略，无内存防护（KASLR/SMAP），漏洞修复早已终止；
• 测试契约失效：Android CTS（Compatibility Test Suite）对 API ≤ 23 的测试套件自 2021 年起不再维护；
• 工具链契约退化：R8 对 minSdkVersion=16 的 D8 字节码优化路径已冻结，无法享受新指令重排与内联优化。

六、决策流程图：何时引用旧 VERSION_CODES？

graph TD A[需做版本判断？] --> B{是否影响用户可见行为？} B -->|否| C[删除判断逻辑] B -->|是| D{是否在 minSdkVersion 与 targetSdkVersion 之间？} D -->|否| E[检查是否属于已知不兼容区间
如 API 16-22：运行时权限/后台服务/通知渠道] D -->|是| F[保留，但必须配单元测试+真机验证] E --> G[禁止使用，改用更高基线或 Feature Flag] F --> H[标注 @SuppressWarnings(\"deprecation\") 并附 Jira 链接]

```