Android Auto认证全链路合规指南：从硬件选型到GMS授权

1. 项目概述：这不是一次简单的“打勾”，而是整车电子电气架构的合规性大考

Android Auto 认证，业内常简称为 AA 认证，绝非在车载信息娱乐系统（IVI）上装个 APK、连上手机点几下就能通过的“功能演示”。它是一套由 Google 官方制定、覆盖硬件设计、软件集成、安全机制、用户交互、数据处理全维度的强制性合规体系。我参与过三款量产车型的 AA 认证全流程，从立项评审到最终拿到 GMS（Google Mobile Services）授权证书，最深的体会是：AA 认证的本质，是把整车厂（OEM）的电子电气开发流程，强行拉进 Google 的生态治理框架里。它不只看“能不能用”，更严苛地拷问“为什么这么设计”“数据怎么流转”“权限是否最小化”“用户是否真正知情并可控”。标题里提到的“立项至量产全链路合规管控”，这十二个字就是整个项目的灵魂——管控不是某个部门的事，而是从项目启动那一刻起，硬件选型、芯片平台、Linux 内核配置、HAL 层接口定义、应用沙箱策略、甚至车机 USB-C 接口的物理引脚定义，都必须同步考虑 AA 的合规红线。相关热搜词里反复出现的“GMS 认证中”“BTS 敏感权限修改”，恰恰印证了这一点：一个看似微小的蓝牙协议栈（BTS）权限调整，可能牵扯出整套车载通信模块的重新测试与文档追溯。而“aa搜狗浏览器”这类热词，则暴露了部分厂商在认证前试图走捷径、绕开 AA 标准 UI 框架的典型误区——结果无一例外，在 Google 的自动化扫描和人工复审环节被驳回。如果你是 IVI 系统工程师、OEM 项目管理负责人，或是 Tier1 的嵌入式软件架构师，这篇内容就是你手边那本没有印刷页码、但每一页都写着“血泪教训”的实战手册。它不讲虚的理论，只告诉你每个阶段“必须做什么”“为什么必须这么做”“不做会死在哪一步”。

2. 全链路设计逻辑与方案选型背后的硬逻辑

2.1 为什么必须从立项阶段就介入？——规避“架构级返工”的唯一路径

很多团队把 AA 认证当成一个“软件测试阶段”的附加任务，等 IVI 硬件已流片、底层 BSP 已冻结、UI 框架已自研完成，才匆忙启动认证。这是最致命的认知错误。我亲眼见过某德系合资品牌的一款主力车型，因立项时未将 AA 的USB Audio Class 2.0（UAC2）音频传输协议栈纳入芯片选型评估，导致后期不得不为满足 AA 对高保真音频通路的强制要求，额外增加一颗专用音频 DSP 芯片，并重写整套音频 HAL 层驱动。项目周期直接延误 5 个月，BOM 成本上升 12%。核心逻辑在于：AA 认证对硬件抽象层（HAL）的接口定义是强约束的。例如，AA 要求android.hardware.audio@2.0HAL 必须完整实现getParameters()、setParameters()等 17 个关键方法，且参数键值（如"audio_hal_version"）必须严格匹配 Google 提供的 AIDL 接口定义。如果芯片原厂 BSP 只实现了 Android 9 的旧版 HAL，而你的项目基于 Android 12 开发，那么从内核驱动、HAL 实现到 Framework 层适配，就是一场从底层开始的重构。因此，立项阶段的“合规预审”清单必须包含：

• 芯片平台是否已通过 Google 的AAOS（Android Automotive OS）兼容性测试套件（CTS）预认证？（注意：不是普通 Android CTS，是 Automotive 专属版本）
• SoC 厂商是否提供符合 AA 要求的Verified Boot 流程文档？AA 强制要求所有固件签名链必须可验证，且 Root of Trust（RoT）必须基于硬件安全模块（HSM）或 TrustZone。
• 车载以太网（如 AVB/TSN）的 MAC 地址绑定策略是否支持 AA 的Device ID 绑定机制？AA 要求每台车机有唯一、不可篡改的设备标识，用于 GMS 服务授权，这与传统 IVI 的 MAC 地址软配置模式存在根本冲突。

提示：不要轻信芯片原厂“支持 Android Automotive”的宣传话术。务必索要其官方发布的《AAOS Compatibility Statement》文件，并逐条核对其中列出的 HAL 版本号、内核配置项（如CONFIG_SECURITY_SELINUX必须=y）、以及是否包含 Google 要求的特定内核补丁（如针对binder驱动的binder_alloc内存隔离补丁）。

2.2 AAOS 与 GMS：两个独立但深度耦合的认证体系

网络热词中频繁混用的 “AA” 和 “GMS”，常让新人误以为它们是一回事。实则不然。AA（Android Auto）是一个投屏协议与用户体验标准，而 GMS（Google Mobile Services）是一套预装应用与云服务授权体系。二者关系如下图所示：

我经手的项目中，曾有团队为赶进度，先拿下 AA 认证，再单独申请 GMS。结果在 GMS 最终审核时，Google 发现其车机的android.hardware.bluetooth@1.0HAL 中，getAddress()方法返回的 MAC 地址与 AAOS CTS 报告中的地址不一致，原因是两套测试使用了不同版本的 HAL 实现。这一处细微差异，导致 GMS 授权被暂停，团队被迫回溯到 HAL 层，统一所有测试环境的代码基线。这说明：AAOS 是地基，GMS 是盖在地基上的第一栋楼；地基没打牢，楼盖得再漂亮也白搭。因此，方案选型时必须明确：你的目标是“支持 AA 投屏”，还是“预装 Google Maps 并获得官方背书”？前者可走轻量级 AA 协议栈集成路线，后者则必须采用完整的 AAOS 发行版，并接受其全套构建与签名流程。

2.3 “BTS 敏感权限”的修改为何如此敏感？——从蓝牙协议栈看 AA 的安全哲学

热搜词中“关于bts敏感权限的修改刚发”，直指 AA 认证中最易被忽视、却最常被驳回的技术雷区。这里的 BTS（Bluetooth Stack），特指车机端运行的蓝牙协议栈实现，如 BlueZ、Fluoride 或 Google 自研的 Bluetooth HAL。AA 对蓝牙的权限控制，远超普通 Android 应用的BLUETOOTH_ADMIN等级。其核心要求是：车机蓝牙模块不得主动扫描、连接或配对任何未经用户明确授权的外部设备，且所有蓝牙通信必须经过 AA 的中央路由（AA Router）进行策略过滤。这意味着，你不能让车机的蓝牙服务像手机一样“自由发挥”。例如，某项目为实现“自动连接车主手机”，在 BlueZ 的main.conf中启用了AutoEnable=true，并在policy.conf中设置了AutoConnect=true。这在功能上很完美，但在 AA 认证中，这属于典型的“越权行为”——AA 要求所有连接动作必须由 AA 的CarBluetoothManagerService发起，并通过BluetoothAdapter.enable()的受控调用完成。原始的AutoEnable会绕过 AA 的权限检查框架，导致cts-tradefed在执行BluetoothDeviceTest#testBluetoothLeScanPermission时直接 Fail。解决方案不是简单地关掉AutoEnable，而是要将该逻辑上移到 AA 的CarService层，通过监听ACTION_USER_PRESENT广播，在用户解锁车机后，由 AA 框架主动触发连接。这个过程涉及对 AA 源码中packages/services/Car/car-lib/src/com/android/car/bluetooth/目录下CarBluetoothAdapter.java的深度定制。我建议的做法是：在enable()方法中插入一个PermissionChecker回调，只有当调用者 UID 属于com.google.android.projection.gearhead（AA 主包名）时，才允许执行底层 enable 操作。这种“权限闸门”式的改造，才是 Google 认可的合规路径。

3. 核心环节拆解：从硬件准备到量产放行的七道关卡

3.1 关卡一：硬件合规性预检（Pre-HW Validation）

这是整个链条的起点，却常被跳过。AA 认证并非只验软件，硬件层面有明确的物理与电气规范。我们曾因一个 USB-C 接口的引脚定义问题，在首次送测时就被 Google 退回。关键检查项包括：

• USB-C 接口必须支持 Alternate Mode（Alt Mode）：AA 投屏要求 USB-C 接口能切换至 DisplayPort Alt Mode，以传输高清视频信号。普通 USB 2.0 数据线无法满足。车机 PCB 设计时，必须确保 USB-C 连接器的SBU1/SBU2引脚正确接入 SoC 的 Type-C 控制器，并在 BIOS/UEFI 中使能USB Type-C Alternate Mode Support。
• HDMI 输出电路需通过 HDCP 2.2 认证：虽然 AA 投屏本身不强制要求 HDCP，但若车机支持 HDMI 外接显示器（如后排娱乐屏），且该 HDMI 通路与 AA 的 USB-C 视频通路共享同一 GPU 输出，则整个视频链路必须满足 HDCP 2.2。我们曾为一款搭载高通 SA8155P 的车型采购了第三方 HDCP 2.2 Key Provisioning Service（KPS）模块，成本增加 $1.8/台，但避免了因视频版权保护不合规导致的 AA 认证失败。
• 麦克风阵列的物理布局必须符合 Google 的 SNR（信噪比）测试要求：AA 要求车机在 65dB(A) 背景噪声下，语音唤醒（如 “Hey Google”）的识别率 ≥ 95%。这不仅取决于算法，更取决于硬件。Google 提供的《AA Microphone Placement Guide》明确规定：主麦克风中心点距车顶棚垂直距离必须为 850mm ± 25mm，且与方向盘中心点水平夹角需在 15°– 25° 范围内。我们曾因内饰供应商擅自将麦克风移至 A 柱饰板内，导致实测 SNR 下降 8dB，不得不重新开模。

注意：所有硬件检查必须在流片（Tape-out）前完成，并形成《Hardware Compliance Report》，作为后续 GMS 认证的必备附件。该报告需由 OEM 的 EE（电子工程）部门与 Tier1 的硬件设计团队联合签署。

3.2 关卡二：AAOS 构建与 CTS 兼容性测试

AAOS 不是普通 Android 的简单移植。它是一个专为汽车场景重构的操作系统发行版，其构建流程（Build Flow）与标准 AOSP 有本质区别。核心步骤如下：

1. 获取正确的代码基线：必须从 Google 的android.googlesource.com/platform/manifest仓库中，检出与目标车型计划上市时间匹配的 AAOS 分支。例如，2024 年 Q3 上市的车型，应使用android-automotive-14.0.0_r1分支，而非最新的master。master分支包含大量未稳定的功能，会导致 CTS 测试不稳定。
2. 配置vendorsetup.sh：在build/envsetup.sh中，必须添加add_lunch_combo <product_name>-userdebug，其中<product_name>必须与 Google 提供的device/google/<codename>/BoardConfig.mk中定义的TARGET_PRODUCT严格一致。我们曾因产品代号拼写错误（"bramble"写成"bramle"），导致lunch命令无法识别，浪费 2 天排查时间。
3. 执行 CTS 测试：使用cts-tradefed工具运行全套 CTS。重点监控android.car.cts模块，它包含 217 个测试用例，覆盖 CarService、Vehicle HAL、Audio HAL 等核心组件。一个典型失败案例是VehicleHalTest#testGetAllPropertyIds：该测试要求IVehicleHAL 必须返回所有已注册的车辆属性 ID（如VEHICLE_PROPERTY_ENGINE_RPM,VEHICLE_PROPERTY_FUEL_LEVEL）。若 HAL 实现中遗漏了VEHICLE_PROPERTY_HVAC_TEMPERATURE_SET，则整个测试包会 Fail。解决方案是，必须严格遵循 Google 的hardware/interfaces/automotive/vehicle/2.0/types.hal文件，确保所有enum VehicleProperty均被getPropertyList()方法返回。

实操心得：CTS 测试耗时极长（单次全量约 48 小时），建议采用“分层测试”策略。先跑cts-tradefed run cts --plan CTS --module android.car.cts（仅车规模块），确认核心 HAL 无误；再跑android.hardware.cts（硬件抽象层）；最后跑全量。这样可将问题定位时间从 48 小时缩短至 4 小时以内。

3.3 关卡三：AA 投屏协议栈集成与 UX 一致性审查

AA 认证的“灵魂”在于用户体验（UX）的一致性。Google 不允许 OEM 对 AA 的投屏界面做任何视觉或交互逻辑的修改。这包括：

• 禁止自定义启动图标与 Splash Screen：AA 的启动必须是 Google 提供的标准齿轮图标（Gearhead Icon），且加载动画必须是官方提供的gearhead_splash.xml。任何替换为品牌 Logo 的尝试，都会在人工 UI 评审环节被拒。
• 禁止修改导航栏（Navigation Bar）行为：AA 要求车机的 Navigation Bar 必须始终显示，并支持HOME、BACK、RECENTS三个标准按钮。我们曾为提升屏幕利用率，尝试在 AA 活动期间隐藏 Navigation Bar，结果在评审视频中被 Google 明确指出：“Violation of AA UX Guidelines Section 4.2.1 - Navigation Bar Visibility”。
• 语音交互必须无缝接管：当用户说出 “Hey Google, 导航到公司” 时，AA 必须立即接管音频输入，并将指令转发至 Google Assistant。这要求车机的Audio HAL必须正确实现acquireAudioSession()接口，并在onAudioSessionAcquired()回调中，将麦克风流路由至 AA 的AudioRecord实例。一个常见错误是，OEM 的语音助手 SDK 会抢占AUDIO_SOURCE_VOICE_COMMUNICATION，导致 AA 无法获取音频流。解决方案是，在Audio HAL的openInputStream()方法中，加入优先级判断逻辑：当请求源为AUDIO_SOURCE_VOICE_COMMUNICATION且 UID 为com.google.android.projection.gearhead时，无条件授予访问权。

实操心得：UX 评审采用“视频录制+人工审查”模式。Google 要求提交一段 15 分钟的高清操作视频，涵盖所有 AA 核心场景（连接、导航、音乐、电话、语音）。我们发现，最稳妥的做法是：使用一台 Pixel 手机（Google 官方推荐测试机），安装最新版 Google App，并在车机端使用adb shell screenrecord /sdcard/aa_demo.mp4录制。切忌使用模拟器或非 Pixel 设备，因其蓝牙协议栈与 USB 通信时序与真机存在差异，会导致评审视频中出现“连接延迟”等假阳性问题。

3.4 关卡四：GMS 应用集成与安全审计（Security Audit）

通过 AAOS CTS 后，才能进入 GMS 认证。此阶段的核心是“安全审计”，即证明你的车机不会泄露用户数据、不会被恶意应用劫持、不会绕过 Google 的服务授权。关键动作包括：

• 禁用所有非必要调试接口：adb必须在量产固件中完全禁用。ro.adb.secure=1仅是基础，还需在init.rc中移除所有service adbd相关语句，并确保adbd二进制文件不在/system/bin/目录下。我们曾因一个遗留的adbd符号链接未删除，被 Google 的静态扫描工具gms-scan检出，导致审计失败。
• 实施严格的 SELinux 策略：AAOS 的 SELinux 策略文件（/system/etc/selinux/plat_sepolicy.cil）必须包含对 GMS 应用的专属域（Domain）。例如，com.google.android.apps.nbu.files（Google Files）必须运行在gms_files_app域下，且该域只能读取/data/media/0/Download/目录，禁止访问/data/data/下其他应用数据。策略编写需使用sepolicy-inject工具，而非手动编辑.cil文件，以避免语法错误。
• 实现 GMS 许可证绑定（License Binding）：GMS 授权证书（.pem文件）必须与车机的唯一硬件 ID（如 eMMC 的 CID 或 SoC 的 UID）进行密码学绑定。Google 提供的gms-license-tool工具会生成一个license.bin文件，该文件需烧录至车机的misc分区。在系统启动时，GmsCore服务会调用libgmscore.so中的verifyLicense()函数，对license.bin进行 RSA-SHA256 验签。若验签失败，GMS 应用将无法启动。我们为此专门开发了一个烧录工具，集成在产线刷机流程中，确保每台车机的license.bin都是唯一的。

3.5 关卡五：第三方实验室（3PL）认证测试

GMS 认证的最终环节，必须由 Google 授权的第三方实验室（如 UL, SGS, Bureau Veritas）执行。这不是简单的“盖章”，而是一场全面的压力与边界测试。核心项目包括：

• 压力稳定性测试（Stress Stability Test）：连续运行 72 小时，期间每 15 分钟执行一次完整的 AA 连接-断开循环，并同时播放 4K HDR 视频、导航语音播报、后台音乐流媒体。测试要求 CPU 温度不超过 85°C，内存泄漏率 < 0.1MB/hour，且无任何 ANR（Application Not Responding）。
• OTA 升级兼容性测试：使用 Google 提供的 OTA 工具，对车机进行 5 次连续升级（从 v1.0 → v1.1 → v1.2 … → v1.5），每次升级后，必须验证 AA 投屏、GMS 应用、蓝牙电话等所有核心功能 100% 正常。我们曾因一个 OTA 升级脚本中未正确处理vendor.img的校验和，导致 v1.3 升级后android.hardware.graphics.allocator@2.0HAL 加载失败，AA 投屏黑屏。
• 电磁兼容性（EMC）辐射测试：AA 投屏时，USB-C 接口产生的高频谐波必须满足 CISPR 25 Class 5 标准。这要求在 USB-C 连接器附近，必须布置共模扼流圈（CMCC）和 TVS 二极管。我们与 TI 合作，选用了 TPD4S012 集成 ESD/EMI 防护芯片，将辐射峰值降低了 12dB。

注意：3PL 测试费用高昂（单次约 $150,000），且排期紧张。务必提前 6 个月预约，并确保送测样机是 100% 量产状态的固件与硬件。实验室不接受“工程样机”或“Beta 固件”。

3.6 关卡六：Google 内部人工复审（Final Review）

3PL 测试通过后，所有报告将提交至 Google 的 GMS 认证团队进行最终人工复审。这是最后一道，也是最不可预测的关卡。复审重点不是技术细节，而是“合规意图”与“文档完整性”。常见驳回原因包括：

• 文档版本不一致：提交给 3PL 的《Hardware Bill of Materials（BOM）》与提交给 Google 的《Final BOM》中，一个电阻的料号（Part Number）不一致（如RC0402FR-0710KLvsRC0402FR-0710K），即使功能完全相同，也会被驳回，因为 Google 要求所有文档必须“零误差”。
• 变更未走正式 ECN（Engineering Change Notice）流程：在 3PL 测试后，若因产线良率问题，将一个 Wi-Fi 模块从QCA6574更换为QCA6574A，必须向 Google 提交 ECN，并附上两者的射频性能对比报告。我们曾因未提交 ECN，导致复审被挂起 3 周。
• 用户隐私政策（Privacy Policy）链接失效：车机设置菜单中，必须有一个清晰的 “Google 服务隐私政策” 入口，且该链接必须指向 Google 官方托管的、与车机固件版本匹配的政策页面（URL 形如https://www.google.com/policies/privacy/automotive/2024/）。若链接跳转至 404 页面，复审直接 Fail。

3.7 关卡七：量产放行（Production Release）

当 Google 签发 GMS 授权证书（PDF 文件）和 AA 认证徽标授权书（Logo License Agreement）后，项目并未结束。真正的挑战在于“量产放行”：

• 固件签名密钥（Signing Key）必须由 Google 托管：所有量产固件的system.img、vendor.img必须使用 Google 提供的私钥进行签名。OEM 无法自行签名。Google 会为每个项目分配一个唯一的Key ID，该 ID 必须硬编码在车机的bootloader中。我们为此开发了一套密钥分发与注入系统，确保产线刷机设备能安全地从 Google 的密钥管理服务（KMS）中获取临时签名令牌。
• 建立持续合规监控（Continuous Compliance Monitoring）：Google 要求 OEM 每季度提交一份《Compliance Status Report》，内容包括：新发现的 CTS 失败项、已知的 UX 偏差、第三方库的安全漏洞（CVE）修复状态。我们将其集成到 CI/CD 流程中，每次代码合并，都会自动触发 CTS 子集测试，并生成报告。
• 建立快速响应通道（Rapid Response Channel）：Google 会不定期发布《AAOS Security Advisory》，要求在 30 天内修复特定 CVE。我们与 Google 建立了专属 Slack 频道，确保安全公告能在 1 小时内触达项目核心成员，并在 72 小时内给出修复方案。

4. 实操过程详解：从代码提交到产线刷机的完整流水线

4.1 代码基线管理：如何避免“分支地狱”

AAOS 项目最大的协作痛点，是代码基线混乱。一个典型的失败案例是：硬件团队基于android-automotive-13.0.0_r1分支开发 HAL，而软件团队基于android-automotive-14.0.0_r1开发 Framework，导致make编译时，hardware/interfaces/automotive/vehicle/2.0/IVehicle.hal的struct VehiclePropValue定义不一致，编译直接报错。我们的解决方案是建立“三层基线”管理体系：

• L1：Google 官方基线（Immutable）：由架构师每月初从android.googlesource.com同步一次，存于内部 GitLab 的aaos-upstream仓库。此仓库为只读，任何人不得提交。
• L2：OEM 主干基线（Stable）：基于 L1，由集成工程师打上release/v1.0.0Tag，并在此基础上，仅允许合并经过充分测试的 OEM 定制 Patch（如patch-oem-bluetooth-fix）。所有 Tier1 的开发都基于此 Tag。
• L3：项目特性基线（Feature）：每个车型项目（如project-bramble）从 L2 创建独立分支，用于集成车型专属功能（如品牌主题、本地化资源）。该分支的 Merge Request（MR）必须关联 Jira Ticket，并强制要求至少 2 名高级工程师 Code Review。

实操步骤（以同步android-automotive-14.0.0_r1为例）：

# 1. 在 aaos-upstream 仓库中，创建新分支 git clone https://gitlab.internal/aaos-upstream.git cd aaos-upstream git checkout -b android-automotive-14.0.0_r1 origin/android-automotive-14.0.0_r1 # 2. 使用 repo 工具同步全部子模块 repo init -u https://android.googlesource.com/platform/manifest -b android-automotive-14.0.0_r1 repo sync -c -j16 # 3. 生成基线快照（Snapshot） repo forall -c 'git rev-parse HEAD > $REPO_PATH/.git/commit_id' tar -czf aaos-14.0.0_r1-snapshot.tar.gz .repo/manifests/ .repo/projects/ aaos-upstream/

此快照文件将作为 L2 基线的“黄金标准”，所有后续开发均以此为准。

4.2 CTS 自动化测试流水线搭建

手动执行 CTS 是效率黑洞。我们搭建了一套基于 Jenkins 的自动化 CTS 流水线，核心组件如下：

• Docker 化测试环境：使用google/cts官方镜像，确保测试环境纯净。Jenkins Agent 运行在 Ubuntu 22.04 LTS 上，挂载/dev/bus/usb以支持 USB 设备直通。
• 动态设备池管理：通过adb devices实时发现连接的车机设备，并根据设备的ro.build.fingerprint自动匹配对应的 CTS Plan（如CTS_ANDROID_AUTO或CTS_GMS）。
• 失败用例智能分析：当android.car.cts.VehicleHalTest#testGetProperty失败时，流水线会自动执行以下诊断：

  # 获取 HAL 服务状态 adb shell lshal | grep "android.hardware.automotive.vehicle" # 检查 Vehicle HAL 是否正常注册 adb shell dumpsys vehicle # 抓取 HAL 调试日志 adb shell setprop log.tag.VehicleHal VERBOSE adb logcat -b main -b system | grep "VehicleHal"

  并将分析结果生成 HTML 报告，直接定位到hardware/interfaces/automotive/vehicle/2.0/default/VehicleHal.cpp的第 342 行。

实操心得：CTS 流水线必须与代码提交（Git Push）事件联动。我们配置了 Jenkins 的Poll SCM触发器，每 15 分钟轮询一次代码仓库。一旦检测到hardware/interfaces/目录下的文件变更，立即触发对应模块的 CTS 测试。这让我们能在代码提交后 2 小时内获知 HAL 兼容性风险，而非等到月度集成时才发现。

4.3 GMS 许可证烧录与产线集成

GMS 许可证（license.bin）的烧录，是量产前的最后一道工序，必须万无一失。我们的产线集成方案如下：

• 烧录设备：使用定制化的 USB-to-JTAG 调试器，固件由我们自主开发，支持 AES-256 加密通信。
• 烧录流程：
  1. 车机上电，进入fastboot模式。
  2. 产线工控机通过fastboot flash misc license.bin命令，将许可证写入misc分区。
  3. 执行fastboot reboot，车机启动。
  4. 启动后，运行adb shell getprop ro.gsm.license.status，检查返回值是否为valid。
• 防错机制：
  • 双因子校验：烧录前，工控机读取车机 eMMC 的 CID（Card Identification Number），并与 Google 提供的license.bin文件名中的序列号（如license_1234567890.bin）进行比对，不一致则拒绝烧录。
  • 烧录后自检：车机启动后，GmsCore服务会调用libgmscore.so的verifyLicense()函数。若失败，车机会在Settings > About Phone > GMS Status中显示红色警告，并禁止进入主界面，强制返工。

我们为该流程编写了详细的 SOP（Standard Operating Procedure）文档，包含 37 个检查点，如“检查 USB-C 线缆是否为 USB-IF 认证线缆（ID: 2023-XXXXX）”、“确认 fastboot 分区表中misc分区大小 ≥ 1MB”。这份 SOP 已成为产线班组长每日晨会的必读材料。

4.4 UX 评审视频制作规范（Google 官方未明说，但实操必备）

Google 的《AA UX Review Guide》只说了“要录视频”，但没说怎么录。我们踩坑总结出的“黄金 15 分钟”规范如下：

• 设备要求：必须使用 Google Pixel 7 Pro（Android 14），安装 Google App v14.12.12.21，USB-C 线缆必须为 Anker PowerLine III（USB-IF 认证 ID: 2023-12345）。
• 环境要求：在标准光照（500 lux）的暗室中进行，背景为纯灰色（RGB: 128,128,128），消除反光。
• 操作脚本（Must Follow）：
  1. 0:00-0:30：展示车机待机界面，镜头缓慢平移，覆盖整个屏幕。
  2. 0:30-1:00：连接 Pixel 手机，特写 USB-C 插入动作，显示手机端弹出“允许 USB 调试”提示，点击“允许”。
  3. 1:00-3:00：启动 Google Maps，输入“公司”，开始导航。全程开启屏幕录制，确保语音播报清晰可闻。
  4. 3:00-5:00：播放 Spotify 音乐，切换歌曲，调节音量，展示 AA 界面的音乐控制栏。
  5. 5:00-7:00：拨打电话（使用 Google Voice），展示通话界面与挂断操作。
  6. 7:00-10:00：语音交互：“Hey Google, 打开空调”，“Hey Google, 调高温度”，“Hey Google, 播放新闻”。
  7. 10:00-12:00：断开 USB 连接，展示车机自动恢复至待机界面。
  8. 12:00-15:00：重复步骤 2-7，但使用蓝牙连接方式。

注意：视频必须为 MP4 格式，H.264 编码，分辨率 1920x1080，帧率 30fps，码率 ≥ 15Mbps。任何剪辑、加速、画外音，都会导致评审失败。我们使用 OBS Studio 进行录制，并在导出时严格校验 FFmpeg 参数：ffmpeg -i input.mov -c:v libx264 -crf 18 -preset slow -vf "scale=1920:1080,fps=30" -c:a aac -b:a 192k output.mp4。

5. 常见问题与独家避坑指南：那些 Google 文档里不会写的真相

5.1 “GMS 认证中”状态卡住超过 30 天？——检查你的 DNS 配置

这是最普遍、也最容易被忽略的问题。当 Google 的 GMS 认证后台显示 “In Review” 状态长达一个月，而你收到的邮件只是泛泛的 “We are still reviewing your submission”，大概率是车机的 DNS 解析出了问题。GMS 认证流程中，车机需要向 Google 的多个域名发起 HTTPS 请求，包括：

• www.googleapis.com（GMS 许可证验证）
• play.googleapis.com（Play Store 应用更新检查）
• android.clients.google.com（GMS Core 服务心跳）

如果车机的resolv.conf中配置的 DNS 服务器（如8.8.8.8）在你所在的地区被限速或丢包，这些请求就会超时，导致 Google 后台认为你的车机“无法联网”，从而无限期挂起认证。我们的解决方案是：在车机固件中，硬编码 Google 的公共 DNS over HTTPS（DoH）