28、认证与合规：Google 认证要求、CTS/VTS 测试、GAS 合规
做 Android Automotive 系统，最绕不开的一个坎就是认证。说白了，你车机上的系统能不能合法地叫「Android Automotive」，能不能用 Google 的服务，全看这一关过没过。
我最早接触这个领域时，以为只要把系统跑起来、功能调通就完事了。结果项目走到一半，被 Google 的认证要求卡了整整两个月。嗯，从那以后，我再也不敢轻视认证这件事。
Google 认证要求：门槛到底有多高？
Google 对 Android Automotive 的认证，比手机要严格得多。原因很简单——车机涉及安全。你想想看，手机死机了重启就行，车机死机了可能影响驾驶。
认证主要分三大块：
- CTS（Compatibility Test Suite）：兼容性测试，确保你的系统能跑 Android 应用
- VTS（Vendor Test Suite）：供应商测试，验证 HAL 层和内核的合规性
- GAS（Google Automotive Services）：Google 车机服务合规，包括地图、语音、应用商店等
这三者缺一不可。我见过一个团队，CTS 跑过了，VTS 也过了，结果 GAS 合规没通过，最后不得不重新提交。浪费了整整一个迭代周期。
核心要点：Google 认证不是一次性考试，而是持续合规。每次系统更新，原则上都需要重新跑一遍关键测试。
CTS 测试：应用兼容性的守门员
CTS 测试，说白了就是检查你的系统能不能正常跑 Android 应用。Google 提供了超过 2000 个测试用例，覆盖了从 Activity 启动到传感器读取的方方面面。
我个人习惯在每次大版本合入后，第一时间跑 CTS。为什么？因为越早发现问题，修复成本越低。我曾经在项目后期才发现一个 CTS 失败项——原因是内核的 binder 驱动版本不对。改起来倒不难，但重新走一轮回归测试，耽误了整整一周。
CTS 测试的几个关键模块：
| 模块 | 测试内容 | 常见失败原因 |
|---|---|---|
| CTS Core | 基础 API 兼容性 | 系统 API 被裁剪、权限配置错误 |
| CTS Display | 屏幕显示、多窗口 | 分辨率适配、density 配置错误 |
| CTS Audio | 音频路由、焦点管理 | HAL 层实现不完整 |
| CTS Car | 车机特有 API | Vehicle HAL 未实现所有属性 |
我的经验：CTS 测试最好在模拟器上先跑一遍基线，再在真机上跑。这样能快速区分是系统问题还是硬件问题。
VTS 测试：底层系统的质量门
VTS 测试关注的是底层——HAL、内核、Treble 架构的合规性。Google 从 Android 8.0 开始强推 Treble，把 vendor 实现和 framework 解耦。VTS 就是用来验证这个解耦是否成功的。
VTS 测试比 CTS 更「硬核」。它直接操作硬件抽象层，测试你的 HAL 实现是否符合 AOSP 的接口规范。我记得有一次，VTS 测试报了一个 sensor HAL 的失败，原因是某个回调函数的超时时间设置得太短。这种问题在功能测试中根本发现不了，只有 VTS 能抓到。
VTS 测试的核心模块：
- VTS Core：验证 HAL 接口的完整性和正确性
- VTS Kernel：检查内核配置、安全补丁、SELinux 策略
- VTS Performance：测试系统响应时间、内存泄漏等
- VTS Security：验证安全补丁级别、加密实现
注意：VTS 测试对内核版本有严格要求。如果你的内核版本低于 Google 要求的最低版本，VTS 直接不通过。我曾经遇到一个项目，因为用了旧内核，不得不做大量 backport 工作。
GAS 合规：Google 服务的入场券
GAS 合规，是车机能不能用 Google 地图、Google 语音、Google Play 商店的关键。没有 GAS 合规，你的车机就只能用 AOSP 的裸系统——说白了，就是个功能机。
GAS 合规的要求比 CTS/VTS 更「软」，但也更复杂。它不只是一堆测试用例，还包括一系列协议和条款：
- MADA（Mobile Application Distribution Agreement）：Google 应用分发协议
- GAS 服务条款：使用 Google 车机服务的具体约束
- 隐私政策：必须符合 Google 的隐私要求
- 品牌使用规范：Android 和 Google 商标的使用规则
我建议在项目启动阶段就联系 Google 的合作伙伴团队，拿到最新的 GAS 合规文档。不要等到 CTS/VTS 都跑完了才去了解 GAS，那时候发现问题，改起来成本极高。
认证流程：从提交到通过
整个认证流程，我把它总结为四个阶段：
- 预测试阶段：在内部跑 CTS/VTS，修复所有失败项
- 提交阶段：通过 Google 的认证门户提交测试结果
- 审核阶段：Google 工程师审核测试报告，可能要求补充测试
- 通过阶段：获得认证，签署 GAS 协议
这里有个坑——Google 的审核周期是不固定的。我见过最快的一周通过，最慢的拖了三个月。所以，我建议预留至少两个月的认证缓冲期。
知识体系总览
下面这张图，是我对认证与合规体系的总结。你可以把它当作一个检查清单，对照着看自己的项目还差哪些。
避坑指南：我踩过的那些坑
做认证这件事，经验比理论更重要。我分享几个真实踩过的坑：
- CTS 测试环境不一致：我曾经在模拟器上跑 CTS 全绿，结果真机上跑出一堆失败。原因是真机的 GPU 驱动不完整。从那以后，我坚持在真机上跑最终验证。
- VTS 的 kernel 版本陷阱：Google 每个 Android 版本都有最低 kernel 版本要求。我见过一个团队用了 4.14 的 kernel 去跑 Android 12 的 VTS，结果 kernel 测试全挂。最后不得不升级到 4.19。
- GAS 合规的隐私政策：GAS 合规要求车机必须展示完整的隐私政策。我见过一个项目，隐私政策链接写错了，被 Google 打回。这种低级错误，完全可以在内部审核时发现。
- 测试报告的格式：Google 对测试报告的格式有严格要求。我建议直接用 Google 提供的工具生成报告，不要自己拼凑。格式不对，直接拒收。
总结一下：认证与合规不是技术问题，而是流程问题。只要你在项目初期就把 CTS/VTS/GAS 的要求纳入开发计划，按部就班地执行，通过认证只是时间问题。怕就怕在「先做功能，后补认证」——这种思路，十有八九要返工。
好了，关于认证与合规，我就讲这么多。记住一句话：认证不是终点，而是起点。通过认证之后，每次系统更新都要保持合规，这才是真正的挑战。