4. Android Auto系统架构

Android Auto 并不是一个“装在车机里的安卓应用”，而是一套以手机为算力中心、车机为显示与外设终端的分布式系统。理解它的关键在于：手机负责运行应用、渲染画面、处理语音与导航计算；车机负责提供屏幕、扬声器、麦克风、方向盘按键、GPS 天线与车辆总线数据。两者通过 USB 或 Wi-Fi 建立一条受控的“投影通道”，把手机的界面安全地映射到车机屏幕上。

一、手机端与车机端组件构成

手机端是整套系统的“大脑”。在 Android 5.0 及以上系统中，Android Auto 以系统级应用或 Google 应用内模块的形式存在，主要包含以下组件：

• Auto App（投影服务端）：负责启动投影会话、管理应用白名单、将手机界面编码为视频流。
• Car App Library / 模板引擎：把导航、媒体、通讯等应用转换为车机可识别的模板界面，避免应用直接绘制复杂 UI。
• Google Assistant 与语音管线：处理“Hey Google”唤醒、语音识别、意图解析与 TTS 播报。
• Google Maps / 媒体应用：提供导航、音乐、播客等实际内容。
• 投影编码与传输模块：将 H.264 视频、音频、触摸事件、传感器数据打包，通过 AOAP 或 Wi-Fi 通道发送。

车机端则是“终端与网关”。它通常由车厂或 Tier1 集成，包含：

• 投影接收器（Projection Receiver）：解码手机传来的视频流并显示到中控屏。
• 车辆 HAL / CAN 网关：向手机提供车速、挡位、灯光、方向盘按键等车辆信号。
• 音频路由模块：区分媒体音频、导航提示音、语音通话与 TTS，并输出到对应扬声器。
• 麦克风与回声消除：为语音交互提供拾音与降噪。
• 触摸与旋钮输入：把用户操作转换为标准输入事件回传手机。

二、投影模式：Android Auto 的工作方式

Android Auto 采用视频投影模式，而不是把应用安装到车机。手机端把界面渲染成视频帧，经编码后通过 USB 或 Wi-Fi 传到车机；车机只负责解码显示，并把触摸、按键、麦克风、GPS 等输入回传。这样做的原因是：车机硬件生命周期长、算力有限，而手机更新快、算力强，把应用逻辑留在手机可以保证体验一致且安全可控。

投影模式有两种连接形态：

无论哪种方式，投影会话都遵循“发现—认证—协商—传输—结束”的生命周期。车机先通过 USB 描述符或 Wi-Fi 服务发现识别手机，双方交换协议版本与能力集，然后建立视频、音频、输入三条逻辑通道。

三、Google Automotive Services 的角色

Google Automotive Services（GAS）是 Google 面向车厂提供的一套授权服务集合，包含 Google Maps、Google Assistant、Google Play 以及相关账号与云服务。在 Android Auto 场景中，GAS 决定了手机端哪些能力可以被投影到车机：

• Google Maps：提供实时路况、车道级导航与 EV 充电桩信息。
• Google Assistant：支持自然语言控制导航、媒体、通话与车辆功能。
• Google Play：让车机或手机获得经过车规适配的应用生态。
• 账号与隐私框架：统一登录、数据同步与权限管理。

四、通信机制与信号链

Android Auto 的通信可以拆成四条并行的数据流：

1. 视频流：手机 H.264 编码 → USB/Wi-Fi → 车机解码 → 屏幕显示。
2. 音频流：手机音频混音 → 传输 → 车机按通道路由到扬声器。
3. 输入流：触摸/按键/旋钮 → 车机标准化 → 回传手机 → 应用响应。
4. 车辆信号流：车速、挡位、灯光 → 车机 HAL → 手机 → 用于限制交互复杂度。

下面这张图展示了手机端与车机端在投影会话中的核心组件与数据流向：

五、典型场景与常见误区

假设用户用 USB 连接手机与车机，启动导航并播放音乐。手机端 Maps 渲染地图，Car App Library 将其转换为车机模板，编码模块把画面压缩为 H.264 流；车机投影接收器解码后显示在中控屏。用户旋转旋钮选择目的地，车机把旋钮事件标准化后回传手机，Maps 更新路线。同时，车辆 HAL 把车速传给手机，手机在车速超过阈值时自动简化界面交互。

排障时可按“物理层—会话层—数据流—应用层”逐层排查：先确认 USB 线缆与 AOAP 枚举是否正常，再检查投影会话是否建立，然后观察视频、音频、输入三条流是否通畅，最后定位到具体应用或 GAS 服务。掌握这套组件与数据流关系，才能在集成与调试中快速定位问题。