Android是汽车电子的未来吗？
要想实现移动互联上的新功能，老迈的WINCE平台已经力不从心，而Android平台确是一个很好的选择：
Android本身就是Google为了实现其移动互联战略开发的技术平台，对移动互联的技术和功能都支持得非常好；
Android的开放性和针对移动互联形成的强大的生态系统、丰富的应用软件对于消费者有着非常大的吸引力；
Android的用户体验可以做得非常好，可以开发出很炫很酷的UI，重视用户体验，是移动互联时代的一个显著特征。
更准确地说，Android不是车机的未来，移动互联才是。只是比起老迈的WINCE、孤芳自赏的iOS和初来乍到的WIN8，Android确实是最适合车机发展移动互联的平台。
事实上，Android也早已引起了车载设备制造商的强烈兴趣，越来越多有实力的车机厂商将使用Android作为车载设备的基本操作系统。Android是好东西，Android是潮流，其实这个观点是没有多少人否认的，车机界其实最关心的问题是Android用于车机是否足够稳定。
汽车电子难就难在：“航天的要求、消费的价格”。同样的瑕疵问题发生在电脑或者手机上，消费者可能也就是抱怨几句，但发生在车机上就要退货加发飙了，所以再好的东西，如果不能解决稳定性的问题也不能用在车机上。
那么Android是否稳定呢？答案很辩证法：Android既稳定也不稳定。
说Android稳定是因为Android本身就是基于Linux开发的，它的内核就是Linux 2.6，作为全世界最主流服务器操作系统之一的Linux本身就是以稳定著称的，也就是说，Android的先天底子还是很好的。而且作为基本开放源代码的操作系统，Android也提供了深度二次开发的可能，完全有可能实现既满足车载设备的用户体验及操作习惯，又兼容Android第三方软件扩展的可能性。
说Android不稳定是Android到目前为止还主要是为了手机而设计的操作系统，并不适用于车机。而且Android是一个开放系统，用户可以任意安装第三方软件，这些软件往往良莠不齐，对系统的稳定性造成了很大的影响。
但是Android的开放性和强大的生态系统却是Android最大的魅力之一，那么如何平衡稳定性与开放性之间的矛盾呢？目前有三个解决方案：
完全不开放。在系统中去除软件安装功能，这个矛盾也不存在了。但估计愿意采用这种方式的人不多；
半开放。消费者只能安装经过厂家测试的、加上了数字签名的软件（相当于厂家自己建设一个专用的App Store）。这是一个比较折中的办法，不过需要厂家投入人力对其维护，对于比较上规模的厂家是一个方法；
全开放。在消费者安装第三方软件时进行提醒，警告其可能的不良后果。这种做法虽然对稳定性帮助不大，但至少减少了消费者发飙的可能。另外在系统也要增加类似笔记本电脑的Ghost功能的“一键恢复”功能。
虽然Android的稳定性与开放性之间的矛盾是可以解决的。但在面对Android给车机带来的市场机会的时候，必须要明确一点：Android车机首先必须是一个车机，我们采用Android是为了发展车机技术，是Android来适应车机，而不是反过来让车机去将就Android。只有先把传统车机的功能在Android上做完善了，接下来才可能实现Android为汽车带来的移动互联服务。
车载设备作为一个已经发展成熟的商品，有其自身严谨的用户体验和产品定义，把Android应用到车机的目的是要进一步改进、完善和拓展这些用户体验和产品定义，这些“久经考验”的用户体验和产品定义是不能随意改变的，作为车机产品“生命线”的产品易操作性更不能退步。
简言之，Android只是车载设备的功能拓展，而绝不是想法设法把车机变成一个大号的手机。
而目前市场上出现了一些急功近利的做法，不下功夫对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的操作系统是Android，相对比较复杂，而MCU和MPEG的软件一般是小型封闭系统，对比Android会简单得多。由于车机系统涉及到三个硬件内核的三个系统，就需要有一套从硬件到软件的通信协议来保证这三个系统能够协同工作。在传统的车机系统中，由于MPU的功能有限（多作为导航板来使用），操作系统的体系也相对比较简单，这个通信协议的实现一般也无需考虑多个应用和进程同时访问通信协议的情况。
但是在Android上实现该通信协议情况就会有所不同：第一步是要在Linux操作系统核心实现硬件接口驱动，第二步要在Android系统框架层实现协议栈的系统服务，第三步才是定义该系统服务和应用程序之间的接口，并在为车载设备定制的Android应用中使用该接口完成与MCU和MPEG的通信。
其挑战就在于尽管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手机至少需要Menu、Back和Home这3个硬按键，才能保证系统和应用的正常使用。但是对于车载设备不能如此，车机的特点是按键空间有限、情况复杂。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的音频系统服务。
5. 多媒体播放
在车载设备的需求中，多媒体播放功能可谓是重中之重，一个成熟的车载设备多媒体播放至少要具有如下功能：碟片（DISC：DVD，VCD，CD，DVD ROM等）播放，AM/FM RADIO，SD/USB存储设备中的媒体播放和蓝牙音频播放，还可能需要支持iPod/iPhone/CMMB/DVB/XM/HD RADIO等MIDI设备的音视频播放功能。反观Android对多媒体播放的需求则局限于SD，USB及手机内部存储设备的媒体播放以及网络流媒体的播放，由于Android的多媒体系统无法直接兼容DISC和蓝牙音频播放，导致某些Android车载设备索性干脆把碟片播放功能去掉了或者是见了问题绕着走。
车机的媒体播放按照播放原理可以分成2大类，SD/USB存储设备算一类，是可以由MPU负责解码播放的，碟片播放算一类，是只能由MPEG负责解码播放的。而目前的Android多媒体体系结构中，所有的多媒体都是由MPU负责解码播放，因此如果要实现车载设备的多媒体播放需求的话，是不能直接重用原生Android多媒体框架和多媒体应用程序的，而是要在系统框架层深度扩展MPU和MPEG的播放接口，还要为车机设计专门的多媒体应用，以便让Android车机能够完美播放CD，DVD，VCD等车机用户最常用的媒体。同时我们还要优化和加强Android原有的SD/USB的本地播放功能（比如增加即插即用，改进易操作性等），以及Android中最为重要的网络流媒体播放功能，在带给用户传统多媒体播放体验的同时，我们更要让他们真正享受到移动互联网的便利，如此种种，工作量是非常巨大的。
6. 蓝牙功能
车机蓝牙与手机蓝牙名同实不同，车机的蓝牙模块是工作在Slave模式的，也就是说车机的蓝牙模块其实可以理解成一个有用户界面的蓝牙高保真耳机，只能被其他蓝牙Host设备查找连接，而Android手机的蓝牙模块是工作在Host模式，可以主动查找其他蓝牙设备并建立连接。这样的设计就导致原生Android的蓝牙软件是无法给车机重用的，需要在Android的系统框架层开发一个全新的蓝牙系统服务和MCU进行蓝牙控制的交互以实现车载蓝牙电话和蓝牙音频等功能。
7. 为车机应用环境开发专用的桌面系统
在Android中Home是指其桌面系统，桌面系统的设计是否专业？是否适合车载环境？将极大的影响用户的操作体验。
跟Android手机不同的是，车载的“桌面系统”首先是要大图标显示，这对于车机来说是一项很重要且必要的设计。车机上的大图标让用户在开车时能很方便的点击到所想点击的应用。用过Android手机的用户都知道，Android的桌面上的图标都是小图标，为了给车机开发设计符合车机使用的Home桌面，需要修改Android底层代码，包括framework层的代码，保证大图标Icon的获取，不是简单的放大缩小，而是按照大图标实际尺寸显示，并且把用户安装的第三方应用跟系统的图标大小和风格统一起来。
小结：
要想做好一台Android车机涉及的问题还远不止上面提到的7条：Android原有系统服务的裁剪和debug、专门针对车机的UI框架设计、车载专用应用的开发、第三方导航软件的集成、海外版本的支持、多产品动态配置等等……而且还有更加重要的移动互联网服务在车载领域的拓展，这也是车机厂商纷纷选用Android的原因之一，一个成熟的Android车机方案不仅要和传统车机保持一致的用户体验，更要有能力引领Android给车机行业带来的产业革命，要达到这样的目的其开发工作将不仅仅是局限于应用层，同时也需要对系统底层的架构进行重写和二次开发，其难度和工作量都是很大的，这就对能够胜任该任务的Android团队的水平和规模提出了很高的要求。
对车机Android方案的开发体会可以总结为两句话：Android的应用的开发难度不是很大，系统及底层的开发深不可测。