Android是互联网行业巨头Google于2007年11月5日宣布的基于Linux平台的开源手机操作系统的名称，该平台由Linux操作系统核心层、Android系统框架层、UI框架层和众多Android应用程序组成，是首个为移动智能终端打造的真正开放和完整的移动互联网操作系统，被广泛的应用在智能手机和新近兴起的平板电脑领域。

　　作为一个新兴的移动互联网操作系统，Android尽管最初是针对智能手机而设计的，但是由于其自身的移动互联网属性、强大的扩展性和开放性，以及Google从发布至今的不间断版本升级赋予它的极其强大的生命力和无限的竞争潜力吸引了越来越多的终端电子设备采用开放的Android平台作为其操作系统。

　　Android的迅猛发展也引起了车载设备制造商的强烈兴趣，为了拓展更多的市场和服务，越来越多有实力的车机厂商将要使用Android作为车载设备的基本操作系统。但是正如上面提到的Android到目前为止还主要是为了手机而设计的操作系统，并不适用于车机。要想既可以满足车载设备的用户体验及操作习惯，又可以兼容Android的特性，也即移动互联、第三方软件扩展、开放性和更“炫”、更“酷”、更时尚的用户体验，就必须进行深度的二次开发，作为基本开放源代码的操作系统，Android也给我们提供了这样的可能。

　　站在车机行业人士的角度，在面对Android给我们带来的市场机会的时候，我们的头脑还是要更加的清醒和明确：Android车机首先必须是一个车机，我们采用Android是为了发展车机技术，是Android来适应车机，而不是反过来让车机去将就Android。我们只有先把传统车机的功能在Android上做好做完善了，接下来才是Android激动人心的移动互联服务，也就是说Android只是车载设备的功能拓展，而绝不能车机去削足适履变成一个大号的手机或者其他不伦不类的东西。车载设备作为一个已经发展成熟的商品，有其自身严谨的用户体验和产品定义，把Android应用到车机的目的是要进一步改进、完善和拓展这些用户体验和产品定义，这些“久经考验”的用户体验和产品定义不能随意改变，作为车机产品“生命线”的产品易操作性更不能退步。目前市场上出现了一些急功近利的做法，不去下功夫对Android针对车机的实际需求进行深度开发，让车机去将就Android，把Android车载系统做成了不伦不类的大号手机；或者是投机取巧，为了规避把Android车载化改造的难度和辛苦，把传统的车机功能采用MCU、MPEG或者WinCE去实现，美其名曰“双系统Android”，但实际的用户体验很差、很低档，这种行径虽然能够蒙蔽市场于一时，但终究会被市场所识破、所唾弃，成为行业的笑话。

　　我们可以明确地说：Android本身是一个手机操作系统，不对Android进行深度开发，就不可能做出真正的车机来！目前很多所谓的车载Android开发还仅仅局限于应用层的开发，和“深度”二字还扯不上关系。上面提到过Android系统由嵌入式Linux操作系统核心层、Android系统框架层、UI框架层和应用程序组成，而Android车机的深度开发正是针对这4大层次，下面我们简单介绍一下基于Android系统实现车载设备所面临的技术挑战：

1. 在Android上实现车载设备的MPU+MCU+MPEG的通信协议

　　智能车机设备架构的核心是MPU，MCU和MPEG，MPU在车机系统中负责显示用户操作界面，处理车机系统和用户的交互以及需要MPU完成的功能如导航、上网等等；而MCU则是车机系统上重要的控制单元，MPEG则是处理碟片的解码和播放。

　　在基于Android的车机系统中，MPU （目前一般采用ARM的A8/A9内核芯片实现，ARM11跑Android会非常勉强）的操作系统是Android，相对比较复杂，而MCU和MPEG的软件一般是小型封闭系统，对比Android会简单得多。由于车机系统涉及到三个硬件内核的三个系统，就需要有一套从硬件到软件的通信协议来保证这三个系统能够协同工作。在传统的车机系统中，由于MPU的功能有限（很多就仅仅是作为导航板来使用），操作系统的体系也相对比较简单，这个通信协议的实现一般也无需考虑多个应用和进程同时访问通信协议的情况。

　　但是在Android上实现该通信协议情况就会有所不同：Android作为一个强大的移动操作系统，有复杂的多进程和多线程机制，不可避免的在Android上实现这个通信协议要考虑多个应用进程甚至系统服务同时与MCU和MPEG通信的情况，再加上通信协议中的大多数消息都会影响MPU的界面显示，这就决定了该通信协议在Android上必须要以一个Android系统服务的方式实现，需要使用Android系统服务来实现MPU侧的协议栈，需要能够借助Android的进程间通信机制Binder来保证MPU的多个进程能够与MCU和MPU协同工作，同时也能够通过注册回调函数的方式让该系统服务把用户操作或者外设变动以消息的形式上报给应用。因此如果要在Android上实现该通信协议，第一步是要在Linux操作系统核心实现硬件接口驱动，第二步要在Android系统框架层实现协议栈的系统服务，第三步才是定义该系统服务和应用程序之间的接口，并在为车载设备定制的Android应用中使用该接口完成与MCU和MPEG的通信。

　　对于上述通信协议的实现原理绝大多数Android的开发者应该都会有一个初步的认识，挑战就在于尽管Android作为一个强大的移动操作系统已经包含很多常用的系统服务（如电源管理服务，窗口管理服务，电话功能服务，输入法服务等），但是它毕竟不是专门为了车载设备而设计的，它无法预料到一个正规的车载设备要有MPU，MCU和MPEG的通信协议。普通的Android开发者有能力开发很酷很给力的应用界面，是他们根本无须了解Android有哪些系统服务，因为Android SDK已经为应用开发者屏蔽了这些困难，但是对于车机通信协议的开发和实现，Android SDK也已经无能为力，只有那些有能力对Android的Linux核心层、系统框架层以及UI框架进行深入研发的团队，才能完美实现这个车载设备的核心通信协议，而据我们所知目前国内有能力能够做到这一点的团队还是凤毛麟角的。

2. 车载设备的“源”管理

　　说到车载设备，有经验的开发团队都会熟悉一个概念就是“源（Source）”，车机中的源并不抽象，相反它的定义非常具体，所谓的源都是来自于用户的操作，比如插入/拔出SD卡、插入/拔出USB设备、按下导航、收音机或者音乐播放按键、插入/弹出CD、挂倒挡开启倒车摄像头等等。这个概念很好，因为车机用户在开车的时候没有那么多空闲去关注操作，他们能够做的都是最简单的动作，即插即用最好，让他们在开车的时候在操作界面上几十个应用中找到音频播放应用，再找到要播放的文件再选取播放，这可是要人命的事情。可是Android是对这个策略是没有定义的，用过Android手机的朋友都知道，大家都是在一堆应用图标中找到音乐图标，点击运行之后再选歌播放的。因此尽管现在Android的应用功能和界面设计已经很简洁了，但是车载设备的需求是更加给力的简洁，要求与车机周边设备的紧密响应，比如挂倒车挡，倒车摄像界面要马上启动，插入CD要马上启动CD播放器播放音乐，播放音乐过程中停车熄火之后再次启动汽车要能够自动断点播放之前的歌曲等情况都需要在Android车载方案中予以实现。

　　Android车载设备要想完美实现用户的源响应，是不能拘泥于Android的原始设计的，需要对系统框架层，UI框架层和应用层进行深入开发，这个过程很复杂，需要和上面提到的通信协议系统服务交互来进行MPU、MCU和MPEG状态的同步，保证源的切换符合车机的需求，同时车机应用的开发都要遵循源的管理策略，还要保证源的管理不会影响Android第三方应用的正常运行。实际上源相关的Android系统架构改变还远不止于此，本文篇幅有限就不做更多阐述了。

3. 车载设备的按键响应

　　熟悉Android的朋友都清楚 Android至少需要3个硬按键menu，back和home才能保证系统和应用的正常使用，一般情况下这个三个按键是以GPIO的方式和MPU连接，Linux系统核心会把这三个按键的输入中断上报给Android系统框架层，然后由系统框架层转发给应用程序。这是标准的Android移动设备的做法，但是对于车载设备就不是那么简单了，车机的特点是按键空间有限、情况复杂，A型号的车机可能有10个按键，B型号的车机可能就只有3个按键，有的时候还不是按键，是旋钮（旋转编码器）、方向盘控制器或者遥控器。同时车机对这些输入设备的处理也和Android不一样，这些输入设备一般都是统一接在MCU上由MCU来进行处理后再通过上面提到的通信协议来发送给MPU，这就导致Android原本针对按键的输入系统模式无法直接套用在车机上，而且如果某个型号的车机无法为Android提供标准按键就更麻烦了，为了处理上面提到的一系列Android车载设备的按键问题，必须要在Android系统中针对车机的需求进行深入定制。

　　很显然，Android车载系统的按键定制是MPU和MCU通信协议的一个扩展，同样也要对Android系统框架层进行改进，由于牵涉的层次和模块比较多，具有相当的深度和工作量，不是一般的小规模的Android团队可以胜任的。

4. 音频源的管理

　　车机上音频源的管理可谓异常复杂，DISC/SD/USB/AUX/iPod/蓝牙/收音机/导航/游戏等等，都会对硬件设计和软件实现产生很大的影响，传统车机的历史悠久，已经有了很成熟的解决方案。可是要在Android上实现音频切换，还得再起炉灶，Android对自身音频的处理分为：MUSIC/RING/ALARM/SYSTEM/Phone等类型，这些类型都是针对MPU输出的音频的，偏偏车机上有太多的音频不是MPU输出的，比如DISC/收音机/iPod/Aux/蓝牙等，如何把这些音频源的切换和音量控制与可由MPU输出的音频（如SD/USB/导航/游戏）整合到一起？这可是一个大问题。比如播放DVD的时候调整音量，应当要提示用户当前音量，但此时是MPEG输出，MPU并没有音频输出，按照Android现在的策略是如果MPU不输出音频，则只会调整来电铃音的音量（大家可以拿出自己的手机试试），这显然是不正确的，只能重构Android的音频系统服务：既然当前音频源在逻辑上已经切换到MPEG上了，针对音量的调整我们会在重构的音频系统服务中给MCU发送音量控制消息，同时还要修改UI框架层，因为Android原本的音量显示和调整界面也是针对Android的标准音频类型的，我们需要在UI框架层针对每一种音频源类型DISC/收音机/蓝牙等都提供用户自定义音量增益调节功能，并且需要在相应的应用启动之后切换与之匹配的音频源。


推荐阅读：安卓车机发展趋势谈之二：系统稳定性是个伪问题