25、车载系统OTA的兼容性管理：硬件抽象层（HAL）兼容性、内核模块兼容性、应用层API兼容性、vendor接口稳定性
OTA升级最怕什么？我最怕升级完了车机变砖。
你想想看，一辆车在路上跑着，用户收到推送点了个「升级」，结果重启后黑屏了。这可不是手机刷机那么简单，车机出问题是要命的事。所以兼容性管理，说白了就是OTA的「安全底线」。
今天咱们就聊聊，怎么在OTA升级中管好兼容性。我把它拆成四个层面：HAL层、内核层、应用层API、还有vendor接口。一个一个来。
硬件抽象层（HAL）兼容性
HAL是Android系统和硬件之间的「翻译官」。系统想控制摄像头、麦克风、GPS，都得通过HAL接口。
OTA升级时，最怕新系统换了HAL接口，但硬件厂商没跟上。我在项目中遇到过，升级Android版本后，原来的HAL实现没更新，结果摄像头直接打不开了。
核心原则：HAL接口必须保持向后兼容。新版本可以加新接口，但不能删旧接口，也不能改旧接口的语义。
具体怎么做？我建议从这几个方面入手：
- 接口版本号管理：每个HAL模块都定义一个版本号。OTA升级包中要检查版本号范围，不匹配就拒绝升级。
- 接口冻结策略：在某个Android版本发布后，冻结该版本的HAL接口。后续只能新增，不能修改。
- 兼容性测试套件：每次OTA前，跑一遍VTS（Vendor Test Suite）。VTS会验证HAL接口是否合规。
举个例子，Android 12到13的升级中，audio HAL新增了setAudioPortConfig的参数。但旧实现只要返回-ENOSYS，系统就能降级处理。这就是典型的兼容性设计。
小技巧：我习惯在HAL实现里加一个「兼容性日志」。每次调用接口时，记录版本号和调用参数。出问题时，看日志就能定位是哪个接口不兼容。
内核模块兼容性
内核模块是更底层的东西。它直接操作硬件寄存器、中断、DMA。OTA升级如果换了内核，驱动模块必须重新编译。
为什么会这样？因为内核API不是稳定的。Linux内核社区明确说过，内核内部API随时可能变。驱动模块必须和内核一起编译。
我在项目中踩过一个坑：OTA升级了内核版本，但某个传感器驱动是预编译的.ko文件。新内核改了某个内部结构体，驱动加载时直接panic。嗯，从那以后我再也不敢用预编译内核模块了。
解决方案其实就几个：
- 内核模块随系统编译：所有驱动模块都放在系统镜像里，OTA时一起更新。
- 使用设备树（DT）：硬件配置信息放在设备树中，内核和驱动通过设备树匹配。这样硬件变化时，只需要改设备树，不用改驱动。
- AB系统升级：保留两个系统分区。升级时先写备用分区，重启后切换。如果新内核启动失败，自动回滚到旧分区。
注意：有些车厂喜欢用「内核模块热加载」。OTA后不重启，直接insmod新模块。这种做法风险极高，我强烈不建议。内核模块的依赖关系太复杂，热加载很容易出问题。
应用层API兼容性
应用层API是车机App和系统服务之间的契约。OTA升级后，App可能还在用旧API，系统却已经更新了。
Android框架层对API兼容性有严格管理。每个API都有@Since和@Deprecated注解。但车载系统有自己的特殊性——很多API是车厂自己定义的，比如车辆信号接口、空调控制接口。
我建议的做法是：
- API版本化：每个自定义API都带版本号。App调用时，必须声明自己支持的API版本。
- 多版本共存：系统服务同时支持多个版本的API。旧App用旧接口，新App用新接口。
- 兼容性包装层：在系统服务前面加一层「API适配器」。它负责把旧版本调用转换成新版本实现。
举个例子，车载的「车窗控制API」从v1升级到v2。v2新增了「防夹手」参数。但旧App只传了车窗ID和方向。适配层检测到v1调用，自动补上默认的防夹手参数。这样旧App不用改，也能正常工作。
关键点：API兼容性不是「改不改」的问题，而是「怎么改」的问题。加参数、加方法都可以，但不要删、不要改语义。
vendor接口稳定性
vendor接口是车厂和Tier1供应商之间的「握手协议」。它定义了系统如何调用供应商的硬件服务。
这部分最头疼。因为供应商的代码是闭源的，车厂拿不到源码。OTA升级时，如果vendor接口变了，供应商必须重新提供固件。
我记得有个项目，OTA升级后，供应商的蓝牙模块不工作了。查了半天，发现是vendor接口中一个结构体字段顺序变了。供应商的固件是按旧顺序解析的，新系统按新顺序发送，结果数据全乱了。
怎么管？我总结了几条经验：
- 接口契约文档化：每个vendor接口都要有正式的接口文档。包括数据结构、字段顺序、字节对齐、大小端。
- 接口变更评审：任何vendor接口的修改，都要经过车厂和供应商双方评审。评审通过后才能合入。
- 接口兼容性测试：OTA升级包中必须包含vendor接口的兼容性测试用例。升级前跑一遍，不通过就拒绝升级。
- 固件版本匹配：vendor接口和供应商固件版本要绑定。OTA升级时，检查固件版本是否匹配。
我的习惯：在vendor接口定义中，加一个「魔数」字段。每次接口变更，魔数也跟着变。系统启动时，先校验魔数。不匹配就直接报错，避免运行时出问题。
兼容性管理的整体框架
说了这么多，咱们用一张图来总结一下。这张图展示了OTA兼容性管理的四个层面，以及它们之间的关系。
这张图里，上面是软件层（应用API和HAL），下面是硬件层（内核和vendor）。OTA升级时，每一层都要做兼容性检查。任何一个层面出问题，都可能让整个升级失败。
最后说一句，兼容性管理不是一次性的工作。它贯穿在整个OTA开发流程中。从设计阶段就要考虑，开发阶段要测试，发布阶段要验证。只有这样，才能保证每一次OTA都安全可靠。