第30章车载系统集成与发布

课程目录第30章车载系统集成与发布

第30章车载系统集成与发布：CTS/VTS 认证、OTA 打包、系统签名、生产刷机、售后维护

好，终于到了最后一章。说实话，每次走到这一步，我都有种「万里长征走到头」的感觉。但别高兴太早——系统集成与发布，恰恰是整个项目里最容易翻车的环节。我在几个量产项目里都见过，前面开发顺风顺水，结果卡在认证或刷机环节，一拖就是几周。

这一章，咱们就把「怎么把系统真正交到用户手上」这件事聊透。从认证到打包，从签名到刷机，再到售后维护，一条线走完。

30.1 CTS/VTS 认证：车机出厂的「通行证」

CTS（Compatibility Test Suite）和 VTS（Vendor Test Suite），说白了就是 Google 给你发的「合格证」。没有它，你的车机就不能预装 Google 服务，甚至不能叫 Android Automotive。

CTS 测什么？ 主要是应用框架层的兼容性。比如你的系统能不能正确响应 Intent、API 行为是否和 AOSP 一致。我遇到过最坑的一次，是某个定制 Launcher 没正确处理 Home 键事件，CTS 跑了一晚上，挂了 200 多个 case。

VTS 测什么？ 这是给 HAL 和内核准备的。比如你的音频 HAL 是否实现了标准接口、Treble 架构是否合规。嗯，这里要注意——VTS 失败通常意味着你的底层驱动有问题，改起来比 CTS 麻烦得多。

核心要点： CTS/VTS 必须在「user 版本」上跑，eng 版本的结果 Google 不认。我建议你提前在 userdebug 版本上预跑一遍，把明显的问题先修掉。

跑 CTS 的命令其实很简单：

# 跑全量 CTS
run cts --plan CTS

# 跑某个模块
run cts --module CtsGestureTestCases

# 跑 VTS
run vts --plan VTS

但真正要命的不是跑，而是「修」。CTS 失败项经常是几十上百条，你得学会看日志。我个人习惯是先看 test_result.xml，找到失败原因，再去 logcat 里定位具体代码。

小技巧： 如果某个 CTS case 反复失败，试试在 userdebug 版本上手动执行对应的测试 App。有时候是测试框架的问题，不是你的 bug。

30.2 OTA 打包：让系统「空中升级」

车机不像手机，用户不会天天盯着更新。但一旦有安全补丁或功能升级，OTA 就是唯一途径。Android Automotive 的 OTA 基于 A/B 分区（也叫无缝更新），说白了就是系统有两套分区，你在后台更新一套，用户完全无感。

OTA 打包的核心工具是 ota_from_target_files，它把编译产出的 target_files.zip 转换成 OTA 包。流程大概是：

编译出 target_files.zip
生成完整 OTA 包（full OTA）
生成增量 OTA 包（incremental OTA）——需要两个版本的 target_files
签名 OTA 包
上传到 OTA 服务器

命令示例：

# 生成完整 OTA
./build/tools/releasetools/ota_from_target_files \
    -k build/target/product/security/releasekey \
    out/target/product/xxx/obj/PACKAGING/target_files_intermediates/xxx-target_files-eng.xxx.zip \
    update.zip

# 生成增量 OTA
./build/tools/releasetools/ota_from_target_files \
    -i old_target_files.zip \
    -k build/target/product/security/releasekey \
    new_target_files.zip \
    incremental_update.zip

注意： 增量 OTA 包的大小必须严格控制。车机网络环境差，一个 2GB 的包用户可能根本不会下载。我建议增量包控制在 200MB 以内，超过这个数就考虑做完整 OTA。

我在项目中遇到过一个问题：增量 OTA 刷完后，某个预装 App 的数据库不兼容，导致闪退。后来排查发现是 App 的 schema 版本没跟着 OTA 一起升级。所以，OTA 测试一定要覆盖「从旧版本升级到新版本」的全流程，别只测全新安装。

30.3 系统签名：给车机「上锁」

系统签名，说白了就是给每个 APK 和镜像文件打上一个「官方认证」的标记。没有签名，系统根本不会安装你的 App。Android Automotive 的签名体系比手机更严格，因为涉及安全相关的系统服务。

签名文件一般有四个：

文件名	用途	说明
releasekey.x509.pem	公钥证书	用于验证签名
releasekey.pk8	私钥	必须保密，泄露等于系统被攻破
platform.x509.pem	平台证书	用于签名系统级 App
shared.x509.pem	共享证书	用于签名多个 App 共享同一 UID

签名命令：

# 签名 APK
java -jar signapk.jar \
    -w releasekey.x509.pem releasekey.pk8 \
    unsigned.apk signed.apk

# 签名镜像
./build/tools/releasetools/sign_target_files_apks \
    -d build/target/product/security \
    target_files.zip \
    signed_target_files.zip

关键提醒： 私钥文件一定要放在离线环境里，最好用硬件加密机保存。我曾经见过一个团队把私钥放在 Git 仓库里，结果被离职员工带走，整个系统都得重新签名。

30.4 生产刷机：从「开发板」到「量产车」

生产刷机和开发刷机完全是两码事。开发时你只管 fastboot flash，但生产线上要考虑效率、一致性和防呆。

生产刷机通常有两种方式：

USB 刷机： 用 fastboot 或厂商工具，一根线刷完。适合小批量或售后维修。
SD 卡刷机： 把镜像放到 SD 卡里，上电自动刷。适合大批量生产，效率高。

我建议生产线上用 SD 卡刷机，因为不需要每台车都连电脑。但要注意——SD 卡的质量直接影响刷机成功率。我见过一批劣质 SD 卡，刷到一半就报错，整条产线停了半天。

刷机脚本示例（SD 卡方式）：

#!/bin/bash
# 假设 SD 卡挂载在 /mnt/sdcard
# 镜像文件放在 /mnt/sdcard/images/

fastboot flash bootloader /mnt/sdcard/images/bootloader.img
fastboot flash radio /mnt/sdcard/images/radio.img
fastboot flash boot /mnt/sdcard/images/boot.img
fastboot flash system /mnt/sdcard/images/system.img
fastboot flash vendor /mnt/sdcard/images/vendor.img
fastboot reboot

经验之谈： 生产刷机完成后，一定要做「全功能自检」。包括屏幕触控、音频输出、GPS 信号、蓝牙连接等。别等到车交付到用户手里才发现问题。

30.5 售后维护：系统上线只是开始

系统发布后，真正的挑战才刚开始。售后维护主要做三件事：

日志收集： 用户遇到问题，你得能拿到日志。我建议在系统里预置一个「诊断模式」，用户可以通过特定操作（比如连续点击版本号）触发日志打包上传。
热修复： 有些 bug 不需要全量 OTA，可以通过热修复框架（比如 Sophix）动态下发补丁。但注意——热修复不能动系统服务，只能修 App 层的问题。
远程诊断： 车机联网后，后台可以主动拉取车辆状态。比如电池电压、存储空间、CPU 温度等。这些数据能帮你提前发现潜在故障。

我曾经处理过一个售后案例：用户反映车机偶尔黑屏，但重启后就正常了。我们远程拉取日志后发现是某个系统服务的内存泄漏，连续运行 72 小时后 OOM 被 kill。后来通过 OTA 修复了这个问题，前后只用了两周。

注意： 售后维护一定要有「回滚机制」。如果 OTA 升级后出现严重问题，用户应该能手动回退到上一个版本。我建议在 bootloader 里保留一个「恢复模式」，通过物理按键触发。

30.6 知识体系总览

下面这张图，把整个集成与发布流程串起来了。你可以把它当作一个「检查清单」，每做完一步就打个勾。

这张图里，CTS/VTS 认证和 OTA 打包是「开发阶段」的核心，系统签名贯穿始终，生产刷机是「生产阶段」的关键，售后维护则是「运营阶段」的保障。每一步都环环相扣，缺一不可。

好了，这一章的内容就到这里。系统集成与发布，说白了就是「把代码变成产品」的最后一步。它不酷，但很重要。希望你在实际项目中，每一步都能走得稳一点、细一点。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录