26、合规与认证：Google Automotive Services (GAS) 认证，CTS/VTS 测试
说实话，做车机系统最头疼的往往不是技术难点，而是「合规」这两个字。你代码写得再漂亮，功能再炫酷，过不了 Google 的认证，那就是一块砖头。今天我们就来聊聊 GAS 认证和 CTS/VTS 测试，这两个东西是 Android Automotive OS 上车的「准生证」。
GAS 认证到底是什么？
GAS，全称 Google Automotive Services。说白了，就是 Google 把自家那套服务——地图、语音、应用商店——打包成一个「合规包」，车厂必须通过认证才能用。
我记得第一次接触 GAS 认证时，心里还嘀咕：不就是装几个 Google 应用吗？后来发现完全不是那么回事。认证的核心是「一致性」——你的车机必须和 Google 定义的规范一模一样，不能改，不能删，不能加私货。
GAS 认证的核心要求：
- 必须预装完整的 GAS 套件（Google Maps、Google Assistant、Google Play Store 等）
- 系统 UI 必须符合 Android Automotive 设计规范
- 必须通过 CTS/VTS 测试
- 必须签署 Google 的兼容性协议
你想想看，Google 为什么要搞这么严格？其实是为了保证用户体验的一致性。你在沃尔沃上能用 Google Maps，换到宝马上也应该能用，而且体验差不多。如果每个车厂都魔改一遍，那 Google 的服务就乱套了。
CTS 测试：应用兼容性的「照妖镜」
CTS，全称 Compatibility Test Suite。它是 Google 用来检测你的系统是否「兼容 Android」的工具集。我习惯把 CTS 比作「照妖镜」——你系统里任何不符合 Android 规范的地方，它都能照出来。
CTS 测试覆盖的范围很广：
- API 行为：你的系统必须正确实现所有公开 API
- 权限管理：权限弹窗、授予、撤销必须符合规范
- 多用户支持：车机通常有驾驶员和乘客模式，CTS 会检查多用户切换是否正常
- 音频焦点：导航语音和媒体音乐不能打架
我曾经在一个项目里遇到过 CTS 测试失败，原因是「音频焦点处理不符合规范」。当时我们自定义了音频策略，想让导航语音一直打断音乐。结果 CTS 测试用例跑不过，因为 Google 要求「导航语音结束后必须恢复音乐」。嗯，这就是典型的「想当然」导致的坑。
我的建议：CTS 测试最好在开发早期就引入。不要等到所有功能开发完了再跑 CTS，那时候发现问题改起来成本极高。我一般会在每个 Sprint 结束时跑一次 CTS，确保没有引入新的兼容性问题。
VTS 测试：底层硬件的「体检报告」
VTS，全称 Vendor Test Suite。它和 CTS 不同，CTS 测的是应用层，VTS 测的是底层硬件抽象层（HAL）和内核。
VTS 测试主要关注：
- HAL 接口实现：你的音频 HAL、摄像头 HAL、传感器 HAL 是否实现了所有必须的接口
- 内核配置：内核是否开启了必要的配置选项
- 系统安全性：SELinux 策略、文件权限、进程隔离是否到位
- 性能指标：启动时间、内存占用、帧率是否达标
说实话，VTS 测试比 CTS 更让人头疼。因为 CTS 出问题，通常是你代码写错了；VTS 出问题，往往是硬件厂商的驱动或内核有问题，你只能催着芯片厂商修。
我记得有一次 VTS 测试卡在「Sensor HAL 的 getSensorList() 返回空列表」上。查了两天，发现是传感器驱动没有正确注册。最后是芯片厂商发了一个补丁才解决。所以我的经验是：VTS 测试一定要留足时间，尤其是第一次做认证的项目，至少预留 2-3 周专门修 VTS 问题。
认证流程：从开发到拿证
整个认证流程大致是这样的：
- 预测试阶段：在开发板上跑 CTS/VTS，确保基本功能没问题
- 正式测试：把完整的车机系统提交给 Google 认证实验室
- 问题修复：Google 会返回一份测试报告，列出所有失败项
- 重新提交：修复所有问题后，再次提交测试
- 拿证：所有测试通过后，Google 会颁发 GAS 认证证书
注意：认证不是一劳永逸的。每次系统大版本升级（比如从 Android 12 升级到 Android 13），都需要重新认证。另外，如果 Google 发布了新的 CTS/VTS 版本，你也需要及时更新并重新测试。
核心知识体系
下面这张图是我自己整理的 GAS 认证与 CTS/VTS 测试的核心逻辑，你看完应该能对整个体系有个清晰的认知：
避坑指南：我踩过的那些坑
做 GAS 认证这几年，我踩过不少坑。挑几个典型的说说：
- CTS 测试环境不一致：有一次我在开发板上跑 CTS 全过，但提交给 Google 实验室就失败。后来发现是测试环境的 Android 版本不一致。记住：CTS 测试必须使用 Google 官方提供的测试环境和工具链。
- VTS 测试超时：VTS 有些测试用例对时间要求很严格。我曾经遇到一个摄像头 HAL 的测试，因为驱动初始化太慢导致超时。解决方案是优化驱动加载流程，或者调整内核的启动参数。
- GAS 套件版本不匹配：GAS 套件和 Android 系统版本必须严格对应。Android 12 的系统必须用 Android 12 的 GAS 套件，混用会导致认证失败。
我的小技巧：每次提交认证前，我会在本地跑一遍「全量 CTS + 全量 VTS」，然后把日志保存下来。如果 Google 那边报失败，我可以快速对比日志，定位问题。这招帮我省了不少时间。
总结一下
GAS 认证和 CTS/VTS 测试，说白了就是 Google 给车机系统设的一道「门槛」。过了这道门槛，你的车机才能用上 Google 的服务；过不了，那就只能自己搞一套生态了。
我个人觉得，做认证最重要的是「敬畏规范」。不要想着走捷径，不要觉得「差不多就行」。Google 的测试用例设计得很全面，你任何偷懒的地方都会被揪出来。老老实实按照规范来，反而能少走弯路。
好了，今天就聊到这里。如果你正在做车机认证，希望这些经验能帮你少踩几个坑。