3. 版本迁移基础
在Android BSP工程实践中，“版本迁移”并不是简单地把AOSP源码换成一个新分支重新编译。它本质上是一次跨层级的系统重构：上层Android框架、HAL接口、内核驱动、厂商闭源模块、板级配置与量产工具链需要在新旧版本之间重新对齐。理解Android版本演进规律、AOSP与厂商BSP的边界关系，以及迁移的驱动因素与目标，是后续制定迁移方案、评估工作量和控制量产风险的前提。
一、Android版本演进的基本规律
Android版本演进可以从三个维度观察：API Level、系统架构变化和Treble化程度。API Level决定应用兼容性边界；系统架构变化影响HAL、Native服务与框架耦合方式；Treble化程度则决定厂商BSP能否与AOSP系统镜像解耦升级。
- API Level递增：每个大版本对应固定API Level，应用与系统服务接口随版本调整，BSP中涉及系统接口的定制需要同步适配。
- 架构持续解耦：从Android 8.0引入Treble开始，HAL被标准化为HIDL，Android 10后逐步转向AIDL，Vendor与System分区边界越来越清晰。
- 内核与GKI演进：Android 11起推广GKI，Android 12/13强化KMI稳定接口，内核驱动逐渐从“跟内核树强绑定”转向“以模块和稳定接口对接”。
- 安全与启动链强化：AVB、dm-verity、SELinux、Keystore、Verified Boot等机制逐版本收紧，迁移时必须重新验证启动链与权限策略。
这些演进规律意味着：迁移不是单点替换，而是沿着“应用—框架—HAL—内核—Bootloader—硬件”的纵向链路逐层确认兼容性。
二、AOSP与厂商BSP的关系
AOSP提供的是Android开源基础框架、系统服务、构建系统和参考实现；厂商BSP则是在AOSP之上，为特定SoC和板卡补齐硬件相关代码、闭源二进制、配置与工具。两者关系可以概括为“AOSP定接口与框架，BSP定硬件与实现”。
Vendor BSP = Bootloader + 内核/驱动 + 厂商HAL + 闭源固件 + 板级配置 + 量产工具
在Treble之前，厂商代码大量侵入 frameworks/base 和 system/core，迁移时冲突面极大。Treble之后，Vendor实现被约束在 vendor 分区，通过HIDL/AIDL与System通信，迁移工作更多集中在VINTF兼容性、HAL版本匹配和内核接口稳定性上。
三、迁移的常见驱动因素
BSP版本迁移通常不是技术团队主动“追新”，而是由产品、供应链、安全与生态共同驱动。常见因素包括：
| 驱动因素 | 典型表现 | 对BSP的影响 |
|---|---|---|
| 芯片平台升级 | SoC换代或新SDK发布 | 内核、驱动、HAL需整体切换 |
| 安全补丁与合规 | Google GMS认证、CVE修复 | 启动链、SELinux、Keystore需重验 |
| 应用兼容性 | 新App要求更高API Level | 框架接口与系统服务需同步升级 |
| 客户/项目需求 | 定制功能、行业认证 | Vendor扩展与AOSP基线需重新对齐 |
| 维护成本 | 旧分支停止维护、补丁难合入 | 长期看迁移可降低维护复杂度 |
四、迁移目标与典型场景
迁移目标必须可量化，否则容易陷入“编过就算成功”的误区。一个可交付的迁移目标通常包括：
- 功能对齐：显示、触控、Camera、Audio、Wi-Fi/BT、Sensor、USB、充电等关键模块全部可用。
- 兼容性通过：VTS、CTS、GTS、STS等测试达到项目准入要求。
- 性能达标：开机时间、内存占用、功耗、温升不劣于旧版本基线。
- 量产可交付：烧录、校准、老化、OTA、恢复出厂等工具链完整可用。
五、常见误区与复盘要点
实际项目中，迁移失败往往不是技术难度，而是边界与顺序没有理清。常见误区包括：
- 把迁移当编译问题：只关注能否build通过，忽略VINTF、SELinux、AVB等运行时约束。
- 过早合并厂商定制：在AOSP基线未稳定前就大量合入Vendor补丁，导致问题定位困难。
- 忽略闭源模块：预编译so、firmware、校准参数未同步更新，导致功能“看起来有、实际不可用”。
- 缺少回归基线：没有旧版本性能与功能数据，迁移后无法判断是否退化。