Head Unit Integration Guide (HUIG) 4.3
第 0 章：引言（Introduction）
0. 引言概述
当今的移动设备集成了尖端技术------包括最新的硬件与软件、高速移动网络，以及不断扩展的互联服务与应用程序生态。这些技术的融合，为用户提供了全新的方式来通信、享受数字内容、获取信息、学习，并探索周围世界。
然而，这些设备并非为驾驶场景设计。在驾驶过程中直接操作手机存在显著的安全风险。
为此，Android Auto （www.android.com/auto）应运而生。它实现了移动设备与车辆之间的无缝集成，使驾驶员能够通过一个更简单、更安全的车载界面，访问并控制移动设备上的技术功能。
本指南描述了如何通过 Android Auto Projection （AAP） 技术，使汽车车载信息娱乐系统 （IVI） 能够利用现代移动设备的计算能力、连接能力和应用生态。
本文件面向希望在其车机（Head Unit, HU） 的汽车信息娱乐系统开发团队，旨在帮助其通过 Android Auto 认证。
⚠️ 注意 ：
本指南不涉及 AAP 协议底层实现细节 （如序列化格式、网络帧结构等），这些由 Google 提供的 Sender/Receiver 库 在 HU 与移动设备（MD）两端自动处理。
如需协议细节，请参考：
0.1 规范性用语约定（Conventions）
本文档中使用的关键词 "MUST" （必须）、"MUST NOT" （不得）、"REQUIRED" （必需）、"SHALL" （应）、"SHALL NOT" （不应）、"SHOULD" （建议）、"SHOULD NOT" （不建议）、"RECOMMENDED" （推荐）、"MAY" （可以）、"OPTIONAL" （可选）等，均遵循 IETF RFC 2119 标准 的定义。
- MUST / SHALL：表示绝对强制要求，违反将导致认证失败。
- SHOULD / RECOMMENDED：强烈建议遵循，以确保最佳用户体验。
- MAY / OPTIONAL：可选实现，不影响基本功能认证。
**0.2 关于 Android Auto Projection（AAP）
Android Auto Projection （AAP） 是连接移动设备与车辆的桥梁，使驾驶员能够通过车辆提供的物理人机交互界面（HMI）（如触摸屏、旋钮、语音按钮等）来访问移动设备的功能。
在 AAP 架构中：
- 移动设备 （MD）负责管理所有用户界面 （UI）、应用逻辑 、网络连接 及计算资源；
- 车机（HU）则作为显示与输入终端，接收来自 MD 的投影内容，并将用户操作反馈回 MD。
这种架构充分发挥了车辆与移动设备各自的优势，共同打造最优驾驶体验：
| 来源 | 提供的能力 |
|---|---|
| 车辆 HU | • 更适合驾驶场景的 HMI（如大按钮、语音优先） • 高精度车辆数据（如 GPS、轮速、档位、燃油状态等），提供更准确的驾驶环境上下文 |
| 移动设备（MD） | • 最新的计算硬件平台（如高性能 CPU/GPU） • 最新的操作系统与安全更新 • 高速移动网络（5G/4G）连接云端服务 • 快速迭代的软硬件生态（消费电子级更新节奏） |
✅ 核心理念 ："App 在手机跑，界面在车机显" ------ 手机是"大脑"，车机是"眼睛和手"。
**0.3 传输层（Transport）
AAP 协议本身是传输无关 （transport-agnostic） 的，只要传输通道具备足够带宽与低延迟，即可运行。
目前官方平台支持的传输方式包括：
- USB 2.0：自 Android Auto 诞生起即支持，为有线连接标准；
- 无线局域网 （Wi-Fi）：自 AAP v1.4 起支持，车机作为 Wi-Fi 接入点（AP），手机连接至 HU 建立点对点通信。
📌 图 0.1：Android Auto 网络栈 （原文配图，此处略）
展示了从物理层（USB/Wi-Fi）到 AAP 协议层，再到各功能通道的数据流向。
**0.4 通信通道（Channels）
AAP 协议定义了多个独立逻辑通道，用于在 MD 与 HU 之间高效传输不同类型的数据流：
| 通道名称 | 方向 | 功能说明 |
|---|---|---|
| Control（控制通道） | 双向 | 负责链路初始化、通道建立（如媒体、输入等子通道的协商） |
| Video Output（视频输出） | MD → HU | 传输 H.264 编码的视频流，用于在主中控屏显示 AAP 界面 |
| Audio Output（音频输出） | MD → HU | 传输媒体音频（如音乐、导航提示音），通过车载扬声器播放 |
| Vehicle Data（车辆数据） | HU → MD | 上传车辆传感器数据（如 GPS 位置、车速、转向角、燃油量等），供导航/应用使用 |
| Input（输入事件） | HU → MD | 将车机 HMI 输入（触摸、按键、旋钮、方向盘控制等）发送至 MD，驱动应用交互 |
| Microphone Audio（麦克风音频） | HU → MD | 传输车载麦克风采集的语音信号，用于语音搜索、通话等 |
| Bluetooth HFP（蓝牙免提） | 双向 | 专用于电话通话的音频通道（符合 Bluetooth Hands-Free Profile） |
| Application Status & Data（应用状态与数据） | MD → HU | 传输结构化元数据，如： • 导航指令（转弯提示、车道指引） • 媒体播放状态（歌曲名、进度、封面） |
💡 设计优势：通道分离避免了音视频与控制信令互相干扰，提升系统鲁棒性。
**0.5 车机（HU）组件与要求
支持 AAP 的车机系统需包含以下高层组件（与 AAP 相关部分）：
| 组件 | 说明 |
|---|---|
| HU OS（车机操作系统） | 运行车载信息娱乐系统的底层 OS，如 Android Automotive OS、Linux、QNX、Windows Embedded 等 |
| OS 适配层（OS Adaptation Layer） | HU OS 与 AAP Receiver 之间的抽象层，负责： • 实现 AAP Receiver 的接口绑定 • 将 AAP 消息转换为 HU OS 原生调用（如 ALSA 音频、V4L2 视频、输入事件注入等） • Google 提供 Android 与 QNX 的参考实现源码 ，但不提供商业级二进制库 |
| Android Auto Projection Receiver（AAP 接收器） | HU 端的 AAP 核心实现，以可移植 C++ 源码形式 由 Google 提供给合作伙伴 • 通过 OS 适配层与 HU 的视频、音频、连接、输入等子系统交互 • 负责管理 AAP 会话生命周期、通道建立、错误恢复等 |
⚠️ 重要提示 ：
本指南不涵盖 HU 完整软件栈（如 CAN 总线驱动、图形合成器、电源管理等），仅聚焦 AAP 集成相关部分。
**0.6 车辆类型（Vehicle Types）
AAP 可集成于以下类型的车辆信息娱乐系统：
| 车辆类型 | 定义 | 集成要求 |
|---|---|---|
| 乘用车（Car） | 无需商业驾照即可驾驶的车辆（如私家轿车、SUV） | ✅ 支持（R00-010） |
| 后装车机（Aftermarket HU） | 为乘用车设计的第三方替换主机 | ✅ 支持（R00-020） |
| 商用车/卡车（Truck） | 需要商业驾照驾驶的车辆（如货运卡车、巴士） | ✅ 支持（R00-030），但有特殊限制 |
针对卡车的强制要求（R00-060）
由于 Google 地图等导航应用未针对商用车辆优化（如限高、限重、危险品路线等），若 AAP 集成于卡车 HU，则：
-
每次启动 AAP 时 ，HU 必须 显示一条可关闭的原生免责声明，内容为：
"Some Android Auto navigation apps are not designed for commercial vehicles and may not be used for navigation."
（"部分 Android Auto 导航应用并非为商用车辆设计，不可用于导航。"）
-
例外 （R00-070）：
若用户在某台手机上明确选择"不再显示" （如勾选 "Do Not Show Again"），则 HU 可记住该设备的偏好，后续连接时不再弹出该提示。
🌍 本地化要求 ：免责声明文本需提供目标市场的官方语言翻译版本。
总结
第 0 章明确了 Android Auto Projection 的设计哲学 、技术架构 、通信模型 及适用范围，为后续章节的具体实现要求奠定了基础。开发团队需特别注意：
- 安全第一：所有设计围绕"减少驾驶分心"展开；
- 职责分离：MD 负责计算与逻辑，HU 负责交互与传感；
- 通道隔离：音视频、控制、数据独立传输，保障稳定性；
- 合规强制：卡车场景的免责声明是认证硬性要求；
- 参考实现：Google 提供 C++ 源码与 OS 适配参考，但需自行集成。