21、车载系统版本管理：版本号规范、构建变体、发布流程与OTA通道管理
版本管理这件事，说实话，在手机圈里已经玩得很成熟了。但到了车载领域，情况就复杂得多。我最早接触车载OTA时，以为就是把手机那套搬过来，结果第一个项目就被版本号搞晕了——车厂有自己的一套命名规则，Android原生版本号又不能动，两边怎么对齐？
今天我们就来聊聊车载系统版本管理的几个核心环节。说白了，就是解决三个问题：你的系统叫什么名字？怎么构建出来的？怎么安全地推给用户？
版本号规范：Android版本 + 厂商定制版本
车载系统的版本号，从来不是单一的数字。它必须同时承载两层信息：Android原生基线版本和厂商定制版本。
我个人习惯的做法是采用三段式或四段式结构：
格式：Android版本.厂商主版本.厂商次版本.构建号
示例：12.3.1.20250315
含义：
- 12：Android 12 基线
- 3：厂商主版本（大功能迭代）
- 1：厂商次版本（小功能或Bug修复）
- 20250315：构建日期（方便追溯）
你可能会问，为什么不直接用Android的版本号？嗯，这里有个坑——车厂通常有多个车型、多个SKU，每个车型的定制内容不同。如果只用Android版本号，你根本分不清这个包是给哪款车用的。
实际项目中的版本号示例：
| 字段 | 示例值 | 说明 |
|---|---|---|
| Android基线 | 13 | Android 13 |
| 厂商主版本 | 2 | 第二代车机平台 |
| 厂商次版本 | 5 | 第五次OTA更新 |
| 构建号 | B1234 | Jenkins构建编号 |
我曾经遇到过一个项目，版本号只写了“V2.0”，结果测试团队拿到的包和产线烧录的包完全不是一回事。后来我们强制要求版本号必须包含构建日期和Git commit hash，这才彻底解决了追溯问题。
构建变体：user / userdebug / eng
Android的构建变体，说白了就是三种不同的“调试级别”。我刚开始带车载项目时，团队里有人问：“为什么不用eng版本直接发布？”——这个问题差点让我血压升高。
三种变体的核心区别：
- user：正式发布版本。没有root权限，adb默认关闭，日志输出受限。性能最优，安全性最高。
- userdebug：介于user和eng之间。有root权限，adb默认开启，但部分调试功能受限。适合开发自测和QA测试。
- eng：工程版本。完全开放，所有调试功能可用。性能最差，绝对不能用于发布。
重要提醒：车载系统发布时，必须使用user版本。我曾经见过某团队用userdebug版本做小批量路测，结果因为日志系统持续写盘，导致eMMC寿命提前耗尽。嗯，这个教训挺深刻的。
构建命令示例：
# user版本
source build/envsetup.sh && lunch car_product-user && make -j16
# userdebug版本
source build/envsetup.sh && lunch car_product-userdebug && make -j16
# eng版本
source build/envsetup.sh && lunch car_product-eng && make -j16
你想想看，如果发布时误用了eng版本，adb端口暴露在车机上，黑客通过Wi-Fi就能连进来——这可不是闹着玩的。
版本发布流程
车载系统的发布流程，比手机严格得多。原因很简单：手机死机可以重启，车机死机可能出事故。
我参与过的项目，发布流程大致分为五个阶段：
- 代码冻结：所有功能开发完成，禁止合入新代码。只允许Bug修复。
- 内部测试：QA团队在userdebug版本上执行全量测试。包括功能测试、性能测试、压力测试。
- 候选版本：切换到user版本，生成RC（Release Candidate）。进行实车路测。
- 小批量推送：选择5%-10%的车辆，推送RC版本。监控反馈数据。
- 全量发布：确认无重大问题后，逐步放开推送比例，直至100%。
我的经验：在候选版本阶段，一定要做一次“回滚测试”。确保如果新版本有问题，车辆能顺利回退到旧版本。我曾经因为忘记测试回滚，导致一批车卡在OTA中途，最后只能进店刷机。
OTA通道管理：Stable / Beta / Canary
OTA通道，说白了就是给不同用户群体推送不同版本的“管道”。我最早做车载OTA时，只设了一个通道——所有车都推同一个版本。结果呢？一旦版本有问题，所有车都遭殃。
现在标准的做法是分三个通道：
| 通道 | 推送范围 | 版本质量 | 典型用途 |
|---|---|---|---|
| Canary | 内部开发人员（<1%） | 可能不稳定 | 验证新功能、早期Bug复现 |
| Beta | 内部测试 + 自愿者（5%-20%） | 基本稳定 | 功能验证、兼容性测试 |
| Stable | 所有用户（100%） | 经过充分验证 | 正式发布 |
通道管理的核心逻辑：
// 伪代码示例：根据通道选择推送策略
if (channel == "canary") {
pushToDevices(deviceList = internalDevices, percentage = 1%);
autoRollback = false; // 需要人工介入
} else if (channel == "beta") {
pushToDevices(deviceList = betaTesters, percentage = 10%);
autoRollback = true; // 发现问题自动回滚
} else if (channel == "stable") {
pushToDevices(deviceList = allDevices, percentage = 100%);
autoRollback = true;
requireApproval = true; // 需要发布审批
}
我个人建议，在车载系统中，Canary通道一定要严格控制数量。手机Canary可以推给几千人，但车载Canary最好控制在几十台车以内。为什么？因为车机出了问题，用户可能直接开到4S店投诉，而不是像手机用户那样默默重启。
知识体系总览
下面这张图，是我对本章内容的一个总结。你可以把它当作版本管理的“地图”：
版本管理这件事，看起来是“定个规则、写个脚本”就能搞定。但真正做过车载项目的人都知道，每一个细节都关乎安全。版本号写错了，可能导致回滚失败；构建变体选错了，可能泄露系统权限；发布流程跳过了，可能让所有车都变砖。
嗯，今天的内容就到这里。记住一句话：版本管理不是技术问题，是管理问题。规则定好了，流程走顺了，OTA才能成为“让车越用越好”的工具，而不是“让车越用越糟”的噩梦。