2. Android系统版本基础
在量产升级与版本管理工作中，最先要建立的能力不是刷机，而是“看懂版本”。同一台设备上，Android 版本号、API Level、安全补丁级别、Vendor Patch、Treble 兼容性、Mainline 模块版本，分别代表不同层面的兼容边界。如果把它们混为一谈，就会出现“系统升级了但 HAL 不兼容”“补丁级别对了但 CTS 不过”“OTA 包能装但无法回滚”等典型量产事故。
一、Android 版本号命名规则：面向用户的版本标识
Android 的公开版本号通常由“主版本.次版本.修订号”构成，例如 Android 13、Android 14。自 Android 10 起，Google 取消了甜品代号作为正式名称，但内部仍保留代号，如 Android 13 对应 Tiramisu，Android 14 对应 UpsideDownCake。量产中更应关注的是版本号背后的 API Level 与 安全补丁级别，而不是营销名称。
在设备“关于手机”页面，常见字段包括：Android 版本、Android 安全更新程序级别、基带版本、内核版本、内部版本号。内部版本号通常由厂商自定义，例如 UP1A.231005.007 是 Google 的 Build ID 格式，厂商会追加机型与区域标识。量产升级脚本中，必须通过 ro.build.version.release、ro.build.id、ro.build.version.security_patch 等属性精确识别，而不能依赖界面显示。
二、API Level：应用与框架的兼容契约
API Level 是 Android 框架对应用暴露的整数接口版本。每个 Android 版本对应一个 API Level，例如 Android 12 对应 API 31，Android 13 对应 API 33，Android 14 对应 API 34。应用通过 targetSdkVersion 声明目标 API，系统据此决定是否启用兼容行为。
量产升级中，API Level 影响三类问题：第一，预置应用是否能在新框架上运行；第二，CTS/GTS 测试用例是否随 API 变化；第三，OTA 包中的 compatibility.zip 是否匹配。若把 API Level 与 Android 版本号混用，会导致升级包校验失败。
# 查看设备关键版本属性
adb shell getprop ro.build.version.release # Android 版本，如 13
adb shell getprop ro.build.version.sdk # API Level，如 33
adb shell getprop ro.build.version.security_patch # 安全补丁，如 2023-10-05
adb shell getprop ro.build.id # Build ID
adb shell getprop ro.vendor.build.security_patch # Vendor 补丁级别三、安全补丁级别：两个日期，两个责任方
安全补丁级别（Security Patch Level，SPL）是形如 2023-10-05 的日期，表示该版本已合入截至该月的 Android 安全公告修复。关键点是：系统存在 Framework SPL 与 Vendor SPL 两个值，分别由 ro.build.version.security_patch 和 ro.vendor.build.security_patch 表示。
在 Treble 架构下，Vendor 分区与 System 分区解耦，因此两者可以不同。量产要求通常是：Vendor SPL 不得低于 System SPL 所依赖的最低值，否则会出现 CVE 未修复或 VTS 失败。升级时若只更新 System 而忽略 Vendor，安全扫描会直接判定不合规。
四、Treble 与 Mainline：解耦与模块化
Treble 是 Android 8.0 引入的架构改造，核心是把 Vendor 实现与 Android 框架通过稳定接口（HIDL/AIDL）分离，使系统升级不再强依赖芯片厂商。它带来 /vendor 分区、VNDK、VINTF 清单与兼容性矩阵。量产中判断 Treble 是否合规，要看 ro.treble.enabled、VINTF 校验结果以及 vndk 版本。
Mainline 是 Android 10 之后推进的模块化更新机制，把部分系统组件做成 APEX/APK 模块，可通过 Google Play 系统更新独立升级，例如 com.android.art、com.android.conscrypt、com.android.media。它让安全修复不必等待完整 OTA，但也带来模块版本与系统版本不一致的排障复杂度。
五、量产场景：一次 OTA 升级的版本核对清单
假设某机型从 Android 12（API 31）升级到 Android 13（API 33），升级包由 System + Vendor + Bootloader 组成。升级前必须完成以下核对，否则极易变砖或 CTS 失败。
| 核对项 | 属性 / 文件 | 升级前 | 升级后目标 | 风险 |
|---|---|---|---|---|
| Android 版本 | ro.build.version.release | 12 | 13 | 应用兼容性 |
| API Level | ro.build.version.sdk | 31 | 33 | CTS 用例变化 |
| System SPL | ro.build.version.security_patch | 2022-09-05 | 2023-10-05 | 安全合规 |
| Vendor SPL | ro.vendor.build.security_patch | 2022-08-05 | 2023-09-05 | VTS 失败 |
| Treble 兼容 | VINTF manifest / matrix | 通过 | 通过 | HAL 不匹配 |
| Mainline 模块 | apexinfo / pm list packages | 旧版 | 随 OTA 更新 | 模块回滚 |
六、排障复盘：三个高频误区
- 误区一：只看 Android 版本号。 版本号相同不代表 API Level 与 SPL 相同，不同批次的量产包可能差异很大。
- 误区二：忽略 Vendor SPL。 Treble 设备上 System 升级后，Vendor 未同步，安全扫描会报 CVE 未修复。
- 误区三：把 Mainline 模块当成普通 APK。 APEX 模块有独立版本与回滚机制，升级失败可能导致系统无法启动，必须纳入回滚策略。
# 量产版本指纹采集示例
adb shell getprop | grep -E "ro.build.version|ro.vendor.build.security_patch|ro.treble.enabled"
adb shell apexinfo list | head -20
adb shell pm list packages --apex-only掌握这些概念后，升级工作就从“刷一个包”变成“核对一组版本契约”。版本号面向用户，API Level 面向应用，SPL 面向安全，Treble 面向分区解耦，Mainline 面向模块更新。只有把它们放在同一张版本矩阵中管理，量产升级才具备可预测性与可回滚性。