Android各API Level对应哪些系统版本和代号？

Question

**常见技术问题：** 在Android开发中，经常需要根据`targetSdkVersion`或`minSdkVersion`配置兼容性行为，但开发者常混淆API Level、系统版本号（如14.0）与代号（如UpsideDownCake）之间的对应关系。例如，“API Level 34对应哪个Android版本？Android 15的正式代号是什么？API Level 21是否等同于Android 5.0 Lollipop？”这类问题频繁出现在适配新特性（如隐私沙盒、通知权限变更）或排查`Build.VERSION.SDK_INT`判断逻辑错误时。由于Google自Android 10起逐步弱化代号宣传，且预览版（Beta/DP）与正式版API Level可能相同但行为有异，导致构建脚本、CI环境或条件编译易出错。此外，部分文档未及时更新（如将Android 14误标为Vanilla Ice Cream），进一步加剧理解偏差。能否提供一份权威、精简、持续可查的API Level ↔ Android版本 ↔ 代号映射表，并说明各版本关键兼容性变更节点？

Answer 1

```html

一、核心概念辨析：API Level ≠ Android版本号 ≠ 代号

这是所有混淆的起点。Google官方定义：

• API Level：整数标识（如34），代表Android框架公开API的向后兼容契约版本，由Build.VERSION.SDK_INT返回，是编译期与运行时判断兼容性的唯一权威依据；
• Android版本号（如14.0、15.0）：面向用户的语义化版本，对应具体系统功能集与生命周期管理；
• 代号（如UpsideDownCake）：内部开发代号，仅用于预览阶段命名，自Android 10起不再作为正式发布名称对外宣传，且Google明确声明“代号不构成API契约的一部分”。

⚠️ 关键事实：API Level在Beta/DP阶段即冻结，但行为可能随正式版调整（如Android 14 QPR2修复了NotificationChannel.setImportance()在targetSdk=34下的静默降级逻辑）。

二、权威映射表（持续可查｜截至2024年9月Android 15 Beta 4）

API Level	Android 版本号	正式代号	首次发布日期	关键兼容性变更节点
34	14.0	UpsideDownCake	2023-08-15	强制执行POST_NOTIFICATIONS运行时权限；限制后台Activity启动；WebView默认启用Safe Browsing
33	13.0	Tiramisu	2022-08-15	通知权限细化（NEVER_SHOW_AGAIN策略）、MediaStore作用域存储强制启用、BluetoothAdapter.isMultipleAdvertisementSupported()废弃
32	12.1	SPB	2022-01-18	引入android:exported显式声明要求（影响所有minSdkVersion < 31但targetSdkVersion ≥ 31的APK）
31	12.0	Sv2	2021-10-04	作用域存储（Scoped Storage）全面强制；requestLegacyExternalStorage失效；NETWORK_STATS权限移除
30	11.0	Red Velvet Cake	2020-09-08	分区存储（Scoped Storage）默认启用（targetSdkVersion ≥ 30）；getExternalStorageDirectory()返回应用专属目录
29	10.0	Quince Tart	2019-09-03	首次引入分区存储（可选）；后台位置访问需额外权限；getDeviceId()在非系统App中返回空字符串
28	9.0	Pie	2018-08-06	前台服务需声明FOREGROUND_SERVICE；HttpURLConnection默认禁用TLS 1.0/1.1；后台执行限制增强
27	8.1	Oreo MR1	2017-12-05	限制隐式广播注册（Context.registerReceiver()受限）；JobIntentService替代IntentService
26	8.0	Oreo	2017-08-21	后台服务限制（startService()抛IllegalStateException）；通知渠道（NotificationChannel）强制启用
21	5.0	Lollipop	2014-11-12	ART虚拟机默认启用；Material Design主题引入；RecyclerView正式进入Support Library；JobScheduler首现

三、典型问题诊断路径（含Mermaid流程图）

当Build.VERSION.SDK_INT == 34但通知未弹出时，应按以下逻辑排查：

flowchart TD
    A[SDK_INT == 34？] -->|否| B[检查targetSdkVersion是否≥34]
    A -->|是| C[是否已申请POST_NOTIFICATIONS权限？]
    C -->|否| D[动态请求权限并检查grantResult]
    C -->|是| E[是否创建有效NotificationChannel？]
    E -->|否| F[调用createNotificationChannel或createNotificationChannelGroup]
    E -->|是| G[检查channel.importance ≥ IMPORTANCE_DEFAULT]
    G --> H[验证NotificationCompat.Builder设置完整性]

四、工程实践建议：构建可维护的兼容层

避免硬编码数字，推荐使用AndroidX提供的语义化常量与封装工具类：

// ✅ 推荐：使用AndroidX Core库抽象
if (BuildCompat.isAtLeastU()) { // API 34+
    handleAndroid14PrivacyFeatures();
} else if (BuildCompat.isAtLeastTiramisu()) { // API 33
    handleAndroid13NotificationPolicy();
}

// ✅ 封装版本判断工具类（支持CI环境注入模拟值）
public final class ApiLevel {
    public static boolean isAndroid14OrHigher() {
        return Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE;
    }
}

注意：Build.VERSION_CODES.UPSIDE_DOWN_CAKE自androidx.core:core-ktx:1.12.0起可用，无需依赖Android SDK 34编译——这是解决CI脚本因SDK缺失导致编译失败的关键。

五、权威数据源与自动化校验机制

为防止文档漂移，建议在CI中集成校验：

• 主数据源：AOSP Build Numbers（最底层、无延迟）；
• 辅助验证：Android Developers - API Levels（含各版本Behavior Changes链接）；
• 自动化脚本示例（GitHub Actions）：curl -s https://raw.githubusercontent.com/aosp-mirror/platform_frameworks_base/master/core/java/android/os/Build.java | grep 'UPSIDE_DOWN_CAKE ='提取实时API Level值。

Google已在Android 15中将代号正式定为Vanilla Ice Cream（非误标），但该代号仅用于Android 15 DP/Beta阶段，正式发布时将不再使用——这印证了“代号即临时标识”的设计哲学。

```