把汽车变成画布：Android车载应用开发全解析

车载屏幕正在成为移动应用的下一个必争之地。在 Google I/O 的一场技术分享中，Android for Cars 团队的两名开发者关系工程师 Paul Amertsmaw 和 Thomas Weathers 系统拆解了如何用一套代码同时覆盖 Android Auto 与 Android Automotive OS，并详解了 Car App Library 的架构、模板体系，以及最新版本带来的媒体与“停车到驾驶”体验升级。

两个平台，一套目标：让汽车成为你的画布

Android for Cars 并非单一平台。据两位工程师介绍，它包含两条技术路线：Android Auto 是手机驱动的投射系统，应用在手机上运行，再通过有线或无线连接把界面投射到车载显示屏；Android Automotive OS（AOS）则是直接运行在车辆上的 Android 变体，独立于手机，能直接访问空调控制、收音机等车辆硬件，并自带数据连接。AOS 的子集——搭载 Google 内置服务的车型——还会预装 Play Store、Gemini 和 Google Maps。

平台规模是这次分享重点强调的论据：目前道路上有超过 2.5 亿辆兼容 Android Auto 的汽车，Google 内置车型覆盖 16 个品牌、超过 100 款。引用 AAA 的 2024 年美国驾驶调查数据，美国驾驶员平均每天有 60 分钟坐在方向盘后。更关键的是，用户不只在驾驶时触达应用——充电桩前等待、学校门口排队接孩子，都是可挖掘的停留场景。

驾驶中 vs 停车后：两种应用状态决定技术选型

理解车载开发，首先要区分两种运行状态。

驾驶优化体验指车辆行驶时仍可使用的应用，涵盖媒体（音频）、消息与通讯、导航、网约车司机端、兴趣点、物联网和天气等类别。这类应用必须遵守严格的防分心安全标准，界面不能随意绘制。

停车应用则是视频、游戏和浏览器等只能在车辆静止时使用的类别。车辆熄火停稳后，防分心限制解除，开发者可以提供与手机、平板更接近的常规 Activity 体验。但即便如此，仍有车载特有的质量要求，比如清单声明、显示挖孔适配，以及在车辆开始移动时暂停播放。

Wheathers 补充道，他们为此推出了面向停车应用的 Android skill，开发者安装 Android CLI 后，通过 Android skills add Android for apps, parked apps 即可把分步指导接入 AI 代理上下文，自动完成清单配置、窗口内边距处理、返回导航、驾驶员分心限制和播放限制等工作，甚至能在提交 Google Play 前审计视频、游戏或浏览器应用。

防分心（Distraction Optimization）标准是车载应用开发的核心约束，源自美国国家公路交通安全管理局（NHTSA）等机构对驾驶员分心的研究。Android for Cars 将其工程化为一套运行时规则：驾驶状态下，应用界面必须由系统认可的模板渲染，交互元素数量、文字长度、点击区域大小都受限，且禁止视频等动态内容。开发者通过清单中的 androidx.car.app.category 和模板声明来表明应用符合这些规则。若应用在行驶中尝试展示未标记为防分心的 Activity，Android Automotive OS 会主动拦截并显示系统遮挡层，这是平台强制的安全兜底，而非可选项。理解这一点，才能明白为何驾驶优化应用不能像手机应用那样自由绘制像素。

Car App Library：宿主渲染，开发者只喂数据

驾驶优化应用的核心是 Car App Library（CAL），一套 Jetpack 库。它采用模板化框架，提供驾驶优化的用户界面，同时自动适配车辆硬件的各种差异——输入方式、屏幕尺寸、宽高比。

其架构的关键在于宿主-客户端模式。宿主应用（Android Auto 本身，或 Google 内置车型上的 Google Automotive 应用宿主）是系统渲染器，最终控制屏幕上显示什么。开发者并不直接绘制像素，而是把结构化数据和状态喂给 CAL 模板，由宿主以安全合规、防分心优化的布局绘制出来。

具体类结构分三层：Car App Service 是宿主与客户端通信的入口，负责创建 Session；一个 Service 与 Session 是一对多关系，例如导航应用可以为主显示屏和仪表盘集群各建一个 Session，这正是支持多显示屏车辆的方式。Session 内部管理 Screen 实例栈，每个 Screen 由模板类表示——网格、列表等——并拥有自己的生命周期，支撑应用内的用户流程。

模板分为通用模板和专用模板（如导航、兴趣点）。开发者可以混合搭配，在安全框架内保留品牌和体验的定制空间。

Jetpack 是 Google 为 Android 开发者提供的一套库集合，旨在减少样板代码并确保应用在不同 Android 版本和设备上行为一致。Car App Library 作为其中一个成员，遵循相同的发布节奏和向后兼容承诺——开发者引入依赖后，库会自行处理与不同版本宿主应用（Android Auto 或 Google Automotive 应用宿主）的通信协议差异。这意味着开发者无需为每款车型或每个宿主版本单独适配，只需面向 CAL 的模板 API 编程，由库负责协商能力集。这也是“一套代码覆盖两个平台”在工程上可行的基础：CAL 抽象掉了宿主是手机投射还是车机原生这一底层差异。

应用类别与发布状态：开放、Beta、即将推出

车载应用按类别管理，且每类的发布权限不同。媒体应用（仅音频）有两种构建路径：较简单的 Media Browser Service 只提供元数据，由车机信息娱乐界面以车载优化方式渲染播放 UI；或者用 CAL 构建，获得更多样式和呈现控制权。

类别状态分三档：开放意味着任何开发者都能直接提交到生产环境；Beta 允许发布到内部或封闭测试轨道，但进入生产需要被早期访问计划接受；即将推出则表示目前不支持、但有计划。

Paul 在会上宣布了一个重要变化：几周前起，游戏在 Android Auto 和 Android Automotive OS 上的发布已面向所有开发者开放。

CAL 1.9 与 1.10：媒体体验与平台统一

媒体是本次分享着墨最多的场景。去年 CAL 1.8 为媒体应用引入了模板化浏览 UI 和自定义操作，包括媒体播放模板。今年 I/O 推出的 CAL 1.9 进入 Beta，带来一批关键更新：通过 App Expression 实现品牌定制，在保持安全规则的前提下调整颜色和形状令牌；新增 spotlight 区块、紧凑列表项、可滚动 chips 和常驻迷你播放器等 UI 组件；同时把媒体模板支持完整扩展到 AOS，推动两个生态的真正统一。

下一个版本 CAL 1.10 将在年内进入 Alpha，重点是通讯应用的自定义模板、更稳健的车内通话体验，以及面向对话式体验的新应用类别和模板。

Media3 是 Android 官方推荐的媒体播放库，取代了旧的 ExoPlayer 独立依赖和 MediaSession 兼容层，统一了播放器、会话和 UI 组件。在车载场景中，Media3 的 MediaLibraryService 和 MediaController 尤为关键：前者让应用在后台持续持有播放器实例并对外暴露媒体库，后者允许不同界面（手机 UI、车机模板、停车视频 Activity）连接到同一个播放会话，而无需各自创建播放器。这正是后文“停车到驾驶”方案中音频不中断的技术前提——播放状态集中在服务端，界面只是附着其上的控制器，切换界面不会打断解码与输出。

停车到驾驶：让视频与音频无缝接续

Thomas 用一个具体案例演示了 park-to-drive 能力。思路是：车辆静止时授予应用完整的原生 Android Activity 访问权，播放视频等富媒体；一旦挂挡，防分心机制启动，应用退回 CAL 媒体模板，保持合规且不中断的音频收听。

实现上有几个要点。视频渲染表面应直接连接到后台播放实例，而不是在 Activity 里另建播放器——应在主服务（如 Media3 的 Media Library Service）中维护统一的 ExoPlayer，同时处理音频和视频流。行驶中无服务绑定时只解码音频；停车打开视频 Activity 时，把渲染表面挂到服务播放器上，借助 Media3 的 MediaController 直接赋值 playerView.player。

启动入口需要用 parked-only onClickListener 包裹，在媒体播放界面的头部栏提供触发意图。行驶模式下点击会被宿主拦截并显示系统安全提示；停车时回调则通过 car context 启动全屏 Activity。清单中必须把视频目标标记为 distractionOptimized=false，让系统识别这是仅停车工作流。

当车辆从停车切回行驶，如果该 Activity 未被标记为防分心优化却仍然活跃，AOS 会弹出“停车以继续使用”的系统遮挡层。要避免这一屏，正确做法是在 isRequiresDistractionOptimized 求值为 true 时清除视频渲染表面并调用 finish——由于视频 Activity 是叠在 CAL 体验之上启动的，finish 后会直接回到媒体播放模板，音频继续不中断。保持媒体会话作为前台服务运行，是跨状态切换声音连续的关键。此外还应重写 CAL Screen 的 onNewIntent 捕获媒体播放意图，让用户从车机系统媒体小组件深链直达正在播放视图。

开发期验证很简单：在 AOS 上执行 adb emulate driving state drive 或对应 parked 命令，即可在两种状态间切换测试。

从模拟器到真车：起步并不复杂

两位工程师给出的行动建议相当务实：复用现有的自适应应用做停车体验，用 CAL 模板构建安全的驾驶体验；开发调试可以借助桌面主机模拟器、跑在 Pixel 平板上的 AOS，或 Firebase Test Lab。车载生态的入口已经铺好，剩下的就是把应用开上路。

桌面主机（Desktop Head Unit，DHU） 是 Android Auto 开发的标准调试工具，运行在开发机上，通过 USB 或 Wi-Fi 模拟车载显示屏，让开发者在没有真车的情况下预览应用的投射界面和交互。对于 Android Automotive OS，则可以使用运行在 Pixel 平板上的系统镜像或 Firebase Test Lab 中的虚拟设备。这些工具的共同价值在于缩短反馈循环：模板渲染、防分心拦截、停车/行驶状态切换都能在模拟环境中复现，开发者不必等到装车才能发现布局溢出或状态切换问题。真车测试仍是上线前的必要环节，但大部分迭代可以在桌面上完成。