📚 课程目录第1章课程导入

1. 课程导入

Android BSP（Board Support Package）版本迁移，本质上是把一套已经跑通的板级软件栈，从旧基线整体搬迁到新基线，并保证它在真实硬件上稳定、可量产、可维护。它既不是简单的“换内核源码”，也不是“编译通过就结束”，而是横跨 Bootloader、Kernel、HAL、Vendor 分区、编译系统、认证与产线工具的系统工程。本课程的目标，是让你具备独立主导一次 BSP 迁移并完成量产交付的能力。

一、学习目标：从“能编译”到“能量产”

完成本课程后，你应当能够独立完成以下任务：

读懂 SoC 厂商发布的 BSP Release Note，识别基线版本、补丁集与已知限制；
规划迁移路径，判断是“增量合入”还是“基线切换”，并评估工作量与风险；
处理 Kernel、DTS、HAL、Vendor 接口在新旧版本间的差异；
定位启动失败、驱动不匹配、分区校验失败等典型迁移问题；
完成 CTS/GTS/VTS 关键项验证，并输出可交付的量产镜像与烧录工具链。

核心判断标准只有一句话：迁移成功的标志不是“开发板能开机”，而是“产线能稳定烧录、整机能通过认证、售后能追溯版本”。

二、核心概念：先建立正确的对象模型

在动手之前，必须分清几个容易混淆的对象。Android BSP 通常由以下层次组成：

层次	典型内容	迁移关注点
Bootloader	U-Boot / LK / ABL	启动流程、DDR 参数、AVB 校验
Kernel	Linux Kernel、DTS、驱动	版本跨度、API 变更、设备树绑定
HAL / Vendor	HIDL/AIDL 服务、闭源库	接口版本、VINTF 兼容性
Android Framework	AOSP、GMS 集成	API Level、SELinux 策略
交付物	镜像、烧录工具、产线脚本	分区表、签名、版本号规则

其中最容易出问题的是 VINTF 兼容性与 分区布局。前者决定 Framework 能否找到 Vendor 服务，后者决定镜像能否被正确烧录和启动。

三、整体框架：一次迁移的完整链路

下面这张图给出了从旧基线到量产交付的主链路。它同时说明了本课程后续章节的组织逻辑：先做差异分析，再做分层迁移，最后进入验证与交付。

四、方法流程：迁移的四个阶段

阶段一：基线与差异分析。拿到新旧两份 BSP，先比对 Kernel 版本、DTS 节点、HAL 接口版本、分区表与编译配置。输出一份差异清单，标注“必须改、可延后、无需改”。
阶段二：分层迁移。按 Bootloader → Kernel/DTS → HAL/Vendor → Framework 的顺序推进。每层都要能单独启动验证，避免问题叠加。
阶段三：系统验证。先做启动与基本功能验证，再跑 CTS/GTS/VTS 关键项，最后做稳定性与功耗测试。
阶段四：量产交付。固化镜像、签名、烧录工具、版本号与回滚方案，输出 Release Note 与产线作业指导书。

五、典型场景与误区复盘

一个常见场景是：新 BSP 的 Kernel 从 4.19 升到 5.10，DTS 中大量节点属性被重命名，驱动仍按旧绑定解析，结果表现为“开机卡在 Kernel 启动阶段，串口无进一步输出”。此时应优先检查 DTS 与驱动绑定是否匹配，而不是盲目怀疑硬件。

常见误区：
① 只关注 Kernel，忽略 Bootloader 与 AVB 校验；
② 迁移后未更新分区表，导致镜像烧录后无法启动；
③ 用开发板验证通过就认为可量产，忽略产线烧录与校准流程；
④ 没有版本追溯机制，出现问题无法定位是哪次合入引入的。

建议在项目初期就建立一份迁移检查清单，把“基线版本、Kernel 版本、HAL 版本、分区表、签名方式、验证项、交付物”逐项确认。下面是一段可用于记录基线信息的示例：

# bsp_baseline.txt
SOC          = RK3588
OLD_BSP      = rk3588_android12_v1.2
NEW_BSP      = rk3588_android14_v2.0
KERNEL_OLD   = 5.10.110
KERNEL_NEW   = 6.1.25
HAL_LEVEL    = AIDL
AVB_ENABLE   = true
PARTITION    = super / boot / vendor_boot / vbmeta

把这张“迁移地图”放在手边，后续每一章都会回到它：先明确当前处于哪个阶段，再判断需要动哪一层、验证什么、交付什么。这样，BSP 版本迁移就不再是一次冒险，而是一条可管理、可验证、可交付的工程路径。