Android 车载应用开发指南系列文章
Android 车载应用开发指南（1）- 车载操作系统全解析
Android 车载应用开发指南（3）- SystemUI 详解
1 Android Automotive OS 概览
车载 Android 系统也被称为 Android Automotive OS，是对原始 Android 系统的一个功能扩充版本。与手机系统一样，Android Automotive OS 源代码完全开放，第三方供应商和汽车制造商可以官方源码的基础上自行开发和拓展，无论是编程语言还是各项接口，都与 Android 系统保持了一致。 与 Android 手机上的 Google 服务类似，Google 在汽车上也提供了用于汽车的 Google 汽车服务（GAS ，Google Automotive Service），包含有 Google 地图、应用市场、Google 汽车助理等等。Google 汽车服务同样没有开源，而是以软件包的形式提供给制造商。 目前国内汽车搭载的 Android 系统都是在标准的 Android Automotive OS 基础上对架构重新进行了定制 及应用的本地化适配。
2 Android Automotive OS 架构
Android Automotive OS 架构如上图所示。图中绿色部分是 Android 原生的代码，蓝色部分是车厂需要修改或添加功能的代码，紫色部分是集成的第三方应用。不过在国内实际开发中，无论是绿色还是蓝色部分，我们都会根据需要进行修改和裁剪。
System APPS
系统应用，系统应用是为了操作系统能正常、高效工作所配备的各种管理、监控和维护系统的程序。例如：SystemUI、Luancher、系统设置。
OEM APPS
厂商应用，由主机或车厂开发、集成的应用，基本功能都是与车辆有关。例如：用户手册，电源管理、车辆设置等。
3RD Party APPS
第三方应用，在车机中集成各种第三方软件公司开发的 APP。一般以音视频娱乐类为主，例如：哔哩哔哩、爱奇艺等。部分厂商的车机系统中还附带了应用商店，用户也可以在其中选择下载自己需要第三方应用。
Android Framework API
用于实现上层应用与 System Service 通信的接口。
Android System Services
系统服务，不必多说是 Android 系统的核心模块，支持着 Android 系统的正常运行。
Car API
用于实现上层应用与 CarService 通信的接口。
CarService
CarService 是车载 Android 系统新增的核心服务，所有应用都需要通过 CarService 来查询、控制整车的状态。CarService 中包含的车载系统服务非常多，例如：CarInputService 、 CarMediaService、CarPowerManagementService 等等。
Traditional Android HAL
传统 Android 硬件抽象层，就是对 Linux 内核驱动程序的封装，向上提供稳定的接口，屏蔽底层的实现细节，同时还有规避 Linux 内核开源协议的作用。
Vehicle HAL
汽车硬件抽象层，这是车载 Android 系统新增的硬件抽象层，它的作用使用定义标准接口，让 CarService 可以忽略各个汽车厂商的具体实现，也就是说 CarService 负责调用 VehicleHAL 定义的接口，而 Android Automotive OS 中 VehicleHAL 并没有具体的实现细节，所以 VehicleHAL 需要汽车制造商或芯片厂商来实现。
3 常见的车载应用
从事车载应用开发的程序员还是要多了解车载应用，所以再看下常见的车载 Android 应用有哪些。
3.1 系统应用
SystemUI
系统的 UI。SystemUI是一个标准的 android 应用程序，它提供了系统 UI 的统一管理方案。 常见的状态栏、导航栏、消息中心、音量调节弹窗、蓝牙连接弹窗等一系列后台弹窗都是由 SystemUI 模块负责管理。
开发难度：SystemUI作为 Android 系统启动的第一个带有 UI 的应用程序，对启动性能和稳定性都有很高的要求。SystemUI需要管理的模块非常多，导致开发任务比较繁重，有的车载项目会要求SystemUI兼容原有的应用层 API，那么开发难度还会上升。
Launcher
桌面启动器，桌面启动器是帮助用户查找和启动其他应用程序的软件。主要负责摆放小部件，显示其它应用程序入口。
现代智能座舱的 HMI 在设计上，开始赋予 Launcher 越来越多的功能，例如：显示 3D 的车辆模型、地图定位等等。
开发难度：Launcher 是与用户交互最多的应用程序之一，同样对启动性能和稳定性都有很高的要求。Launcher 开发难度主要集中在与 3D 车模的互动（如果有 3D 模型），可能需要支持 Widget 的显示（WidgetHost），各种应用的拖动和编辑等。
Settings
系统设置，是车载 Android 系统中非常重要的一个系统级应用，是整个车载 IVI 系统的控制中心，整车的音效、无线通信、状态信息、安全信息等等都是需要通过系统设置来查看和控制。
开发难度：系统设置主要难度都集中在对 Android Framework 层 API 的理解上，例如蓝牙、Wi-Fi 设置就需要开发人员对系统级 API 有一定的了解。
3.2 多媒体应用
收音机
目前的车载收音机包括传统的模拟信号收音机和现代化的数字信号收音机，根据销售国家的不同，车载收音机支持的种类也有所不同。
AM/FM
最常见的模拟收音机制式，AM - 调幅收音机，FM - 调频收音机。在不同国家和地区，频率范围有一定的差别。
RDS
无线电数据广播（英语：Radio Data System, RDS）是一种在传统的 FM 广播中嵌入少量的数字信息的通信协议标准。它在发射信号时可以利用副载波将电台名称、节目类型、节目内容及其它信息以数字的形式发送出去。
DAB 及 DAB+
数字信号广播（ Digital Audio Broadcasting 简称 DAB）是继 AM、FM 传统模拟广播之后的第三代数字信号广播，它提供了接近 CD 质量的声音，具有抗噪声、抗干扰、抗电波传播衰落、适合高速移动接收等优点。目前主要应用于欧美和香港等地区。
音视频播放
音视频播放属于车内驾驶体验的不可缺少的一部分，现代汽车的音视频播放功能主要用于播放 SD 卡或 U 盘中的离线音视频文件，在线音视频播放功能基本都集成第三应用实现。
3.3 工具类应用
Map
地图，车载系统的核心功能之一，负责导航和语音提示等功能。不同的主机厂商有不同的开发方式。不外乎有三种：
1）选择使用百度、高德的地图 SDK 自行开发导航应用；
2）将导航模块外包给百度、高德，由地图供应商进行定制化开发；
3）直接集成地图供应商已有的车载版本的应用；
开发难度：主要集中在对地图 SDK 的运用和理解上，而且地图应用属于对性能要求较高的模块。
语音识别与语音控制
语音技术在我们的日常生活已经随处可见，汽车可以说是语音技术应用的最佳案例之一。 驾驶过程中驾驶员很难像使用手机那样操作车机系统，语音控制技术的引入可以帮助驾驶员在不额外分心驾驶的基础上，完成各类车辆操控。 目前国内语音供应商非常多，主要有科大讯飞、百度、腾讯、华为等等。
3.4 车控应用
空调（HVAC）
车载空调用于调节车内温度、湿度，给乘员提供舒适的环境。除了基本空调功能外，高级的空调系统还包含，空气净化、香氛系统等等。
车控车设（VehicleSettings）
车控车设主要负责舒适性控制、车辆控制以及智能驾驶。舒适性控制包含座椅通风、座椅姿态控制、车内照明、门窗开闭等等，车辆控制包含刹车辅助、车身姿态控制、方向盘助力等等。 开发难度：主要难度集中在复杂多变的 UI，有的主机厂商会在 HMI 中引入 3D 化的交互模型，就还需要考虑与 3D 模型间的通信，同时还需要熟练运用 CAN 工具来模拟汽车的 CAN 信号用于调试和开发。
3.5 辅助驾驶应用
倒车影像
倒车影像是驾驶辅助系统中的一个重要配置项，在车辆倒车时可通过装备在车辆后方的摄像头，将车后状况实时显示在中控或后视镜的显示屏上，方便驾驶员观察。 倒车影像需要覆盖倒车辅助线，倒车辅助线用于驾驶员判断车辆行驶过程中的轨迹和车辆与物体的距离，通常分为静态倒车辅助线和动态倒车辅助线。动态倒车辅助线的线条会随着方向盘转动而转动，从而准确的描出倒车的轨迹。
360 全景影像
360 全景影像又称全景泊车系统，是 2005 年后逐渐出现的一种泊车辅助技术。早期泊车辅助系统常采用雷达或单摄像头，使用声音报警或显示车辆后方摄像头视频图像的方式，帮助车辆驾驶员判断盲角处车辆与障碍物距离。采用雷达报警方式，距离的显示并不直观；采用后置摄像头方式，则仍会存在盲角和距离判断不准的问题。于是逐渐兴起了全景泊车技术。
3.6 车辆互联
CarPlay
CarPlay 是苹果公司推出的一种车载服务应用，苹果手机连上支持 carplay 的车机后，车机系统界面就会出现手机上的地图和音乐等应用，手机上只要适配了 carplay 功能的应用，都可以在车机屏幕上直接使用。
Android Auto
Android Auto 与 Carplay 类似，是 google 公司推出的车辆互联方案，通过把手机应用界面投射到车载系统上，来取代汽车制造商的原生车载系统来执行 Android 应用与服务。 由于 Android Auto 依赖 Google 服务，所以在国内几乎无法使用，目前国内销售的汽车很少会支持 Android Auto。
CarLife
CarLife 是百度在 2015 年推出的车联网解决方案。和 CarPlay 和 Android Auto 产品相比，CarLife 的用户不用在意自己的智能手机是什么操作系统，只需要通过数据线或者 wifi 将手机连接到车载系统上，就可以使用。 除了以上三种方案，车辆互联方案还有华为的 HiCar 以及小米的 CarWith 等等。
车载的应用远不止以上说得这些，根据不同的需求，还有非常多的 Service 需要做定制化开发，这里只列举了最常见的应用类型。
4 车载应用与移动应用的区别
移动端的应用开发和车载应用开发有很多相似的地方，同时也有一些不同。总结一下大致有以下几个区别：
1）应用级别不同
多数车载应用属于系统级应用 ，可以调用 Android SDK 内部隐藏的 API，也不需要动态地向用户申请权限。移动应用是普通应用，系统对其限制很多，需要遵守 Android 应用的开发规范。
由于车载应用是系统级应用，所以移动端很多常用的技术比如热修复、插件化基本都不会采用，但是相对的进程保活、开机自启就变得非常简单了。
2）迭代方式不同
移动应用只要用户的手机接入了 WiFi 就可以进行在线升级，所以移动应用多采用小步快跑的形式，进行快速迭代。
车载系统级应用的更新只能以整车 OTA 的形式进行，而 OTA 可能会消耗宝贵的车机流量，所以车载应用在 SOP（量产）前，就必须完成全部需求的开发，而且不能出现严重的 bug。在正式交付用户前，车厂内部或 4S 店还会进行几次 OTA 升级用做最后的 bug 修复。
3）技术路线不同
正是因为车载应用对稳定性的要求极高，所以车载应用在开发时，对待新型技术会非常的慎重，比如，目前只有少数主机厂商在使用 Kotlin 开发车载应用，毕竟 Android Framework 都还没有改成 Kotlin，大部分厂商对 Kotlin 的积极性不高。而且车载应用也不允许随意使用开源框架，如果必须使用，务必注意框架的开源协议，以免给汽车厂商带来不必要的麻烦。
4）运行环境不同
车载应用的运行环境是经过高度定制化的 Android 系统，定制化也就意味着 bug。移动端的应用出现 Bug 时，我们的第一反应是应用的代码有缺陷。车载应用发现 Bug 也要考虑到是不是系统本身出现了 Bug ，这是一件非常有挑战性的事，应用开发与系统开发相互扯皮、泼脏水也属于家常便饭。
5 车载应用需要掌握的技能
除了一般 Android 开发需要学习的基础内容外，一名优秀的车载应用工程师还需要掌握以下的技能
1）MVVM 架构
虽然如今一些移动端应用已经开始尝试 MVI 架构，但是就像前面说得，车载应用对待新技术都会持观望态度，目前主流的车载应用还是采用基于 Jetpack 组件的 MVVM 架构。
2）构建系统级应用
由于多数车载应用都属于系统级应用，所以必须了解如何构建一个系统级应用，这方面的内容可以参考书籍《Android 深度探索：系统应用源代码分析与 ROM 定制》。
3）性能优化
应用的性能优化是个亘古不变的话题，掌握应用的各种性能优化方式，也是一个 Android 程序员必备的生存手段，汽车座舱的 SOC 性能比旗舰手机要差不少，如果优化好车载应用将是一个非常有挑战性的任务。
4）IPC 通信
Android 中最常用的跨进程通信手段是 Binder，因为有大量的 Service 需要与应用进行交互，所以基于 Binder 的 AIDL 在车载应用开发中使用得非常广泛，学会使用 AIDL 也同样属于必备技能之一。
5）CAN 仿真测试工具
CAN 仿真测试工具包含了软件和硬件，在车载应用开发时我们需要借助这些工具来模拟发送 CAN 性能给到 IVI 来调试我们的应用，在实车调试阶段，也需要借助这些工具来捕获车辆的 CAN 信号来分析一些 bug。常用的有 CAN alyzer、CANoe、TS-Master 等等，这些工具价格都极其昂贵，独自购买不现实，在车载应用开发务必把握学习和使用的机会。
6）系统应用源码
不少车载应用层项目都是反复定制各种 SystemUI、Launcher、Settings 等等，读懂 Android 系统应用源码对我们定制化开发这些应用有非常大的好处。
以上是一些我认为车载应用开发时需要掌握的技能，其他的一些诸如：adb 调试指令、Linux 操作系统的运用、AOSP 源码编译也都需要额外学习，根据不同的需求，JNI、NDK 等技术也有可能会用上。