大家最熟悉的Android系统应该是手机和平板设备上的，大部分人可能没想过Android系统和汽车有什么关系。但实际上，Android系统在四年前就在布局汽车这个平台。我最近对相关内容做了一些了解。下面将我所了解到的信息分享给大家。

1、Android Auto

Android Auto是一个Android端的App，是专门为驾驶环境而设计的。

运行Android Auto需要Android 5.0或更高版本的系统，并且还需要Google地图和Google Play 音乐应用。

Android Auto可以用来将Android设备上的部分功能映射到汽车屏幕上。

Android Auto在2014的Google I/O上首次亮相。相应的App：Android Auto在2015年3月19日发布。

当Android Auto接到汽车屏幕上其界面看起来是下面这个样子：

当然，也可以不连接汽车，直接在手机上使用，其界面是下面这个样子：

1.1 核心功能

在2014的Google I/O大会上，Google在介绍Android Auto时，首先就是以安全性为引入点的：很多人在开车会使用手机，这就造成大量的交通事故。所以我们应当理解，汽车上的软件功能并非越多越好。某些手机上很受欢迎的功能和软件，它们未必适合车载系统，例如：浏览器网页，阅读，玩游戏，看视频等等。

从上面的两幅图中可以看到，无论是汽车屏幕还是手机屏幕，界面底部包含了四个相同的按钮（虽然位置不同）。

以手机界面的按钮顺序，这四个按钮的功能依次是：

回主界面

地图功能

通话功能

音乐功能

1.1.1 Google Assistant

2007年，iPhone的发布宣示了触摸交互方式的兴起。在这之后，触摸手势彻底代替了物理键盘。

当时的运营商无法想象一个没有物理键盘的手机会被大家喜欢。而在十年之后，曾经能够生产最好的物理键盘手机的制造商，例如黑莓和诺基亚都早已被市场淘汰。

因此我们可以想象，新一代的平台和电子产品有可能会引入新的交互方式，或者是让某个原先不太流行的交互方式成为主流。而对于汽车来说，语音无疑是比触摸更好的交互方式。

在驾驶环境中，语音交互存在如下优势：

用户不用改变自身的物理姿势，所以这种交互方式不影响对于驾驶的操控。

有些需要多次触摸手势的交互，可能一条语音就可以完成。

语音交互不存在入口的层次嵌套，数据更加扁平。

优秀的语音系统可以利用对话的上下文完成任务，避免用户重复输入。

除此之外，在驾驶环境中，对于语音功能的实现也更有利。因为，驾驶舱的空间较小，便于语音数据的捕获；驾驶舱座位的相对位置固定，系统更方便判断发出语音的角色，例如区分发出语音指令的是驾驶员还是乘客而采取不同的处理。

这就不奇怪Google将Google Assistant集成到Android Auto中了。

当语音系统能够获取到用户的基本信息的情况下，很多操作会变得非常便利。例如，直接告诉系统：”我要回家“。而不用先打开地图，然后搜索自己家的地址，然后再点击导航按钮：

当系统有了更多的用户的数据以及外部服务之后，可以做的事情将超远我们现在看到的。例如：在导航至某个餐馆的途中直接帮忙预订座位（今年的Google I/O上，Google已经展示了通过AI完成的电话预订：Google’s AI Assistant Can Now Make Real Phone Calls）。

当然，Google Assistant 不仅仅是为Android Auto设计的，它支持非常多的设备。不过这部分内容已经超过本文所要说明的。

1.2 兼容的车型和应用

现代汽车是首个支持Android Auto的汽车制造商。2015的Hyundai Sonata是第一个支持Android Auto的汽车型号。

到目前为止（2018年7月），支持Android Auto的汽车品牌已经很多，包括：奥迪，别克，凯迪拉克，雪佛兰，福特，本田，吉普，林肯，奔驰，马自达，大众，Volvo等超过50家汽车制造商，超过500种汽车型号。

详细的品牌和型号请参见下面这个链接：Android Auto - The right information for the road ahead 。

目前，支持Android Auto的应用比较少。虽然2018年的Google I/O上宣称这类应用数量正在高速增长，但目前Google Play上支持Android Auto的应用也只有数千款，这与Google Play上的三百多万应用相比，就显得很可怜了。

可以通过这个链接浏览支持Android Auto的应用：Apps for Android Auto。

1.3 App

1.3.1 开发

Android Auto目前仅支持两类第三方的应用：

音频应用：允许用户浏览和播放汽车中的音乐和语音内容。

消息应用：通过text-to-speech朗读消息并通过语音输入回复消息。

为了声明应用支持Android Auto，需要在/res/xml/新建一个XML文件来进行描述。

例如，假设我们创建的文件是automotive_app_desc.xml，其内容是：

这里通过<uses>标签描述了应用所使用的特性：media。name属性目前仅支持两个值：

media：该应用使用Android框架API在车辆中播放音乐。

notification：该应用在汽车的主屏幕中显示消息通知，允许用户选择要朗读的消息，并让他们通过语音输入进行响应。

定义完成该文件之后，需要在AndroidManifest.xml中指定：

之后就是通过相应的API完成功能开发了，这部分内容具体见Android Developer中的文档，这里不再赘述：

Provide audio playback for Auto

Provide messaging for Auto

1.3.2 设计

Google专门为Android Auto上的UI设计做了一个指导网站，具体见这里：Auto UI guidelines。

基本的指导原则包括：

Android Auto上的互动步调必须由驾驶员控制。

汽车界面上的触摸目标必须足够大，以便可以轻松地浏览和点按。

适当的色彩对比可帮助驾驶员快速解读信息并做出决定。

应用必须支持夜间模式，因为过高的亮度可能会干扰注意力。

Roboto字体在整个系统中用于保持一致性并帮助提高可读性。

通过触摸来进行分页应该用来作为滑动翻页的补充。

谨慎和有选择地使用图像。

有节制的使用动画来描述两个状态之间的变化。

这些指导原则也值得其他车载的交互系统借鉴。

1.4 无线

目前的Android Auto需要通过USB线缆将手机连接到汽车上才能使用。

通过线缆连接这个动作对用户来说无疑是一件很麻烦的事情。一来需要将手机从包中取出，二来再次拿手机时还受限于线的长度。所以很显然，无线的使用方式将是未来的设计趋势。这一点，从Apple的AirPods以及近期新上市的手机几乎都会支持无线充电就可以看出。

在功耗和传输性能的限制下，有线设计只是暂时的妥协。不过一旦这些限制逐渐缩小，无线功能自然就会出现了。所以Google在今年提出了无线Android Auto。

可以看一下这个链接：Wireless Android Auto is available for Google phones。

Apple在iOS 9上就支持无线CarPlay了。不过目前只有BMW部分车型支持。

2 Android Automotive

Android Auto是以手机为中心的。这种模型既有好处，也有坏处。

好处是：数据和应用始终是一致的，不存在需要数据同步的问题，手机上装的软件和已有的数据，接到汽车直接就有了。而坏处是，每次得拿出手机，汽车只是手机一个外设。并且，这种模式不便于对于汽车本身的控制和相关数据的获取。

如果是系统直接内置于汽车，那就是完全不一样的体验了。而Android Automotive则是面向这个方向设计的。

可以看一下下面的两个链接：

Volvo’s native Google integration is the next level for Android Auto

For Google, it’s full speed ahead with Android Automotive, but not so much with Android Auto

不过，据报道中的信息，这类产品两年之内恐怕都不会上市。

从这一点来讲，AliOS是完全领先Android Automotive的。因为内置AliOS的荣威RX5早就已经量产了。

一旦将系统内置于汽车，可以完成的功能将大大增加。例如：直接在中控触摸屏上调整空调和座椅。

同时，系统也能获取到更多关于汽车的信息，例如：油耗水平，刹车使用等等。这对于改进驾驶体验是非常有意义的。

内置于汽车内部的系统甚至会影响汽车本身的设计，两者将非常好的融合在一起。

2.1 版本演进

最近几年的Android版本中，每个版本都为Android Auto增加了一些新特性。具体可以观看今年的Google I/O中的相关演讲：What’s new in automotive - Google I/O 2018。

下面是这个演讲中对于版本演进的特性小结：

2.2 源码与架构

Android Automative的源码包含在AOSP中。

关于AOSP以及如何获取源码可以参见其官方网站：

https://source.android.com，这里不再赘述。

如果你不想下载整个源码，只想浏览Android Automative的相关源码，可以直接点击这个链接：/platform/packages/services/Car/。

这里是Android Automative的一些文档。

Android Automative的整体架构如下图所示：

从这幅图中我们可以看出，Android Automative是在原先Android的系统架构上增加了一些与车相关的（图中虚线框中绿色背景的）模块。

包括：

Car App：包括OEM和第三方开发的App

Car API：提供给汽车App特有的接口

Car Service：系统中与车相关的服务

Vehicle Network Service：汽车的网络服务

Vehicle HAL：汽车的硬件抽象层描述

下面我们采取从上到下的顺序对主要模块做一些介绍。

2.3 Car App

/car_product/build/car.mk 这个文件中列出了汽车系统中专有的模块：

这个列表中，首字母大写的模块基本上都是汽车系统中专有的App。

这些App的源码都位于/platform/packages/services/Car/目录下。

当然，OEM厂商可以添加更多的App。

你也可以在/platform/packages/services/Car/目录下通过find . -name AndroidManifest.xml确认哪些文件中包含了Car App。

2.4 Car API

源码：/platform/packages/services/Car/car-lib

开发汽车专有的App自然需要专有的API。这些API对于其他平台（例如手机和平板）通常是没有意义的。所以这些API没有包含在Android Framework SDK中。

下面这张大图列出了所有的Car API：

从这个图中我们可以看到Car API主要包括：

android.car：包含了与车相关的基本API。例如：车辆后视镜，门，座位，窗口等。

cabin：座舱相关API。

hvac：通风空调相关API。（hvac是Heating, ventilation and air conditioning的缩写）

property：属性相关API。

radio：收音机相关API。

pm：应用包相关API。

render：渲染相关API。

menu：车辆应用菜单相关API。

annotation：包含了两个注解。

app

cluster：仪表盘相关API。

content

diagnostic：包含与汽车诊断相关的API。

hardware：车辆硬件相关API。

input：输入相关API。

media：多媒体相关API。

navigation：导航相关API。

settings：设置相关API。

vms：汽车监测相关API，见下文。

2.5 Car Service

源码：

Car service

Android Automative中的Car Service集中在一个App中。可以想象，这个App需要非常高的权限，所以这是一个系统App。其Manifest开头如下：

android:sharedUserId属性使得这个应用具有系统权限。

Car Service并非一个服务，而是一系列的服务。这些服务都在ICarImpl.java构造函数中列了出来。

读者可以浏览这些服务的源码了解其实现。

2.6 Car Tool

还有几个模块没有出现在上面的架构图中。但它们也包含在了Android Automative系统中，这里一并介绍一下。

2.6.1 VMS

VMS全称是Vehicle Monitor Service。正如其名称所示，这个服务用来监测其他进程。

在运行时，这个服务是一个独立的进程，在init.car.rc中有关于它的配置：

如果你不熟悉rc文件请阅读我之前写过的文章：Android系统启动：init进程与init语言

这是一个Binder服务，并提供了C++和Java的Binder接口用来供其他模块使用。

2.6.2 EVS

Android 8.0包含一个汽车 HIDL 硬件抽象层（HAL），可用于在 Android 启动过程的初期提供图像捕获和显示，并在系统启动后继续运行直到系统终止。HAL包含外部视景系统 (Exterior View System，简称EVS) 堆栈，通常用于在具有车载信息娱乐（IVI）系统（基于 Android）的车辆中支持后视摄像头和环绕视图显示。EVS 还支持在用户应用中实现高级功能。

EVS 包括以下系统组件：

EVS应用：该应用负责从EVS管理器请求视频帧，并将用于显示的已完成的帧发送回EVS管理器。EVS和汽车服务可供使用后，它便立即由init启动。OEM可视需要修改或替换EVS应用。

EVS 管理器：EVS管理器可提供 EVS 应用所需的编译块，以实现从简单的后视摄像头显示到6DOF多相机渲染的任何功能。它的接口通过 HIDL呈现，并被编译为接受多个并发客户端。其他应用和服务（特别是汽车服务）可以查询 EVS 管理器状态，以了解EVS系统何时处于活动状态。

EVS HIDL接口：在 EVS 系统中，相机和显示元素均在 android.hardware.automotive.evs 程序包中进行定义。用于实践接口的示例实现（生成合成测试图像并验证图像进行往返的过程）在 /hardware/interfaces/automotive/evs/1.0/default 中进行提供。

内核驱动程序：支持EVS堆栈的设备需要使用内核驱动程序。OEM无需创建新驱动程序，他们可以选择通过现有相机和/或显示硬件驱动程序来支持EVS所需的功能。重复使用驱动程序可能会有好处，对于图像呈现可能需要与其他活动线程协调的显示驱动程序来说尤其如此。

关于EVS的更多内容请参见这里：AOSP camera-hal。

关于HIDL请参见这里：HIDL。

2.6.3 ODB2

源码：

obd2-lib

ODB全称是On-Board Diagnostics。这是一种装置于车中用以监控车辆运行状态和回报异常的系统，可于车辆的子系统出现问题时，产生故障代码和提醒讯号通知车主和车厂诊断维修。1980年车上诊断系统发明后，早期仅能以指示灯形式回报故障发生与否。随着计算机技术的进步，目前已经能回报各式各样的实时数据和标准化故障代码（diagnostic trouble codes，DTC），使得汽车故障诊断维修方法发生翻天覆地的变化。

美国是最早规定车辆必须装配车上诊断系统的国家，之后欧盟与日本也陆续采行。台湾自2008年起实施。中国大陆部分地区则自2006年起陆续对新车推出了装置车上诊断系统的要求。

OBD-II是基于OBD-I的基础上，增加了资料容量并将其标准化。OBD-II明确定义了连接器型式、脚位、可用通讯协定以及讯息格式。OBD-II同时也提供额外可监控汽车参数清单以及编码方式说明。

AOSP中的ODB2库是以一个Java静态库的形式存在的。

它支持多种命令。这些命令按照类型实现在不同的文件中：

2.7 Vehicle Network Service

源码：

vehicle_network_service

libvehiclenetwork

Vehicle Network Service的结构和VMS的结构是类似的，也是一个可执行文件（vehicle_network_service）加一个库（libvehiclenetwork）的形式。

libvehiclenetwork中既包含了C++的库，也包含了Java语言的库。对于需要跨语言访问的数据结构，使用Protocol Buffers 格式描述：libvehiclenetwork/proto/。

Protocol Buffers是Google开发的另外一个工具。它语言中立，平台中立，具有可扩展的机制，用于序列化结构化数据。类似XML，但更小，更快，更简单。

vehicle Network Service的主要作用是通过它来设置HAL属性（见下文HAL）。这些属性在VehicleNetworkConsts.java中已经全部列出：

当然，并非所有模块都有权限设置这些HAL属性。所以这里需要权限的控制。

对于这一点，通过vns_policy.xml来控制。

这个文件中定义了每个属性允许哪个角色访问，以及访问权限是只读（r）还是可读可写（rw）。下面是vns_policy.xml中的一个代码片段：

2.8 HAL

源码：

hardware/libhardware/include/hardware/vehicle.h

hardware/libhardware/modules/vehicle/

车载HAL（Hareware Abstract Layer，硬件抽象层）接口会定义OEM可以实现的属性，并会包含属性元数据（例如，属性是否为 int 以及允许使用哪些更改模式）。车载 HAL 接口是以对属性（特定功能的抽象表示）的访问（读取、写入、订阅）为基础。

2.8.1 HAL接口

车载HAL使用以下接口：

vehicle_prop_config_t const *(*list_properties)(..., int* num_properties) 列出车载 HAL 所支持的所有属性的配置。车辆网络服务只会使用受支持的属性。

(*get)(..., vehicle_prop_value_t *data) 读取属性的当前值。对于区域属性，每个区域都可能具有不同的值。

(*set)(..., const vehicle_prop_value_t *data) 为属性写入相应值。写入的结果是按属性进行定义。

(*subscribe)(..., int32_t prop, float sample_rate, int32_t zones) 监视属性值的变化，回调见下文。

(*release_memory_from_get)(struct vehicle_hw_device* device, vehicle_prop_value_t *data) 释放从 get 调用分配的内存。

车载HAL使用以下回调接口：

(*vehicle_event_callback_fn)(const vehicle_prop_value_t *event_data) 通知车辆属性值的变化。

(*vehicle_error_callback_fn)(int32_t error_code, int32_t property, int32_t operation) 返回全局车载 HAL级错误或每个属性的错误。全局错误会导致HAL重新启动，这可能导致包括应用在内的其他组件重新启动。

2.8.2 属性与区域

每个属性都由 int32 键唯一标识，且具有预定义的类型（value_type）：INT32（和数组）、INT64、BOOLEAN、FLOAT（和数组）、字符串、字节。

区域类型除了值之外还有区域。车载HAL定义了下面几种区域类型：

2.8.3 处理区域属性举例

下面是获取HVAC温度的调用过程。

下面是设置HAVC温度的调用过程。

图中缩写说明如下：

CS：CarService

VNS：VehicleNetworkService

VHAL：Vehicle HAL

3 结束语

最后，我们以Android系统在汽车行业上的发展小结一下车载系统的特点：

保持驾驶安全永远是第一重要，任何新功能的增加都必须先考虑这个原则。

车载系统不是手机系统的简单移植，手机上的应用大部分也不适合车载系统。

车机硬件差异太大，平台需要处理好差异性。

交互方式需要用心对待，以便让用户更容易操作。

界面设计上也需要通过色彩或控件大小以突出重点，让用户更容易辨识。

语音将是车载系统上很重要的交互方式。

导航，多媒体，消息将是车载系统上最主要的应用类型。

无线通信是未来，随着硬件传输速度的提升，各种线缆将尽可能的减少。

车载系统将脱离手机，内置的原生系统能获得更好的体验。