文章来源于网络收集而来，版权归原创者所有，如有侵权请及时联系！

Google I/O 2014 之 Android 面面观

发布于 2022-03-27 22:42:39 字数 22253 浏览 812 评论 0 收藏 0

作为当今移动互联网行业中当之无愧的双雄之一的Google公司，其举办的I/O大会向来受到全世界开发者、科技工作者甚至科技爱好者的倾心关注。2014年6月25到6月26号两天，Google I/O大会如期在旧金山的Moscone Center West举行。在这次会议上，最耀眼的光环无疑属于移动领域中势头最强劲的Android系统。笔者总结此次大会中关于Android的内容大体如下：

Android One：这是一个针对覆盖面多达数十亿人口的项目，其目标是提供100美元以下的Android低端智能设备以替代受众手中的功能机。
最新版的Android操作系统：从这个版本开始，Android系统不再以数字命名，而是以字母代替。此次推出的新版本叫“L”。虽然Google并没有明确说明“L”代表什么，但结合此次大会的情况，我们可以很清晰得看到Android系统将不再局限于智能手机，而是力图覆盖可穿戴设备、TV、车载系统等其他人们日常生活所密切接触得方方面面。所以，“L”更有“Life”之意[1]。
Android Wear、TV和Auto：其中，Wear是针对可穿戴设备的Android系统， TV是针对家庭娱乐核心设备TV上的Android系统，而 Auto是用于车载设备的Android系统。

下面，笔者将从上述五个方向来介绍和分析此次I/O大会中和Android相关的内容。

一 Android One介绍

简单来说，Android One是一系列低端智能Android手机，其目标人群是这个星球上数十亿还在使用功能机的人。由于Android One定位于低端机，出于成本和购买力的考虑，其硬件特性不会强到哪去，但为了用户体验的一致性和连贯性，Google希望Android One的硬件至少支持如下特性：

支持双卡

支持SD卡
4.5寸屏幕
支持FM收音机
价钱少于100美金

从软件特性上看，Android One的特点是：

运行Android系统
能自动安装应用程序
系统能自动升级

点评：Android One是一个极具战略眼光的计划。其实，这几十亿目标人群早就是中国山寨手机厂商或其他主打第三世界国家中低端手机市场的厂商的盘中餐，眼中菜，但Android系统在低端手机软/硬件体系上缺乏某种程度上统一的衡量标准，导致这些厂商的产品鱼龙混杂，良莠不齐。再加上这些厂商只通过卖设备赚取微薄利润，所以很难有心力来真正耕耘这块广阔的市场以及培养用户使用习惯。

Android One的出现能很大程度上改善上述问题，而且可预计得是它将为整个生态系统开辟一块巨大的市场：

Android One制订了一套低端智能手机软/硬件体系的最低标准。下一步Google很可能会和主打生产高性价比芯片的芯片厂商（例如联发科，展讯等）推出一系列Android One参考设计芯片组。OEM厂商可以直接利用这些参考设计芯片来生产符合Android One标准的智能手机。所以，Android One将有利于芯片厂商和OEM厂商。
从这次大会上可知，在印度市场上，Android One手机将通过三个当地的主要运营商发售。所以，运营商也将是Android One计划的直接受益者。
Android One软件系统中肯定会预置Google的服务，也能方便人们下载喜欢的应用程序。所以Android One将为Google及软件开发商开辟了一个之前几乎无法涉足的巨大市场。例如，第三世界很多国家由于经济不发达，人们买不起PC机，也很少上网。现在他们能借助Android One上网下载并使用应用程序，更新系统。在这过程中，Google及应用软件开发商就获取他们感兴趣的数据，以进一步帮助开发商开发更符合当地风俗民情、使用人群的软件。这一块可想象的空间非常大。可预期的是，随着Android One覆盖面的增加，全球移动互联网时代将真正到来。

当然，Android One也会对其他一些定位于低端手机的厂商或OS开发商（例如Nokia的功能机以及Mozilla的FireFox OS）造成较大的冲击。

二 Android L介绍

Android L号称是Android历史上改动最大的一个版本，新增和修改多达5000个左右的API。从整体情况来看，Android L有以下几个方面值得重点关注：

全新的UI/UE设计风格和框架Material Design以及和通知（Notification）栏有关的UI/UE变化。
能大幅改善系统运行速度的运行时库Android Runtime（简称ART）。
致力于改善功耗的Project Volta。

先来看Material Design以及相关的UI/UE改进。

1. Material Design及Notification变化

Material Design是Google此次推出的一套全新的UI/UE设计风格和框架。直白得说，Material Design是一种改进后的扁平化设计风格，它在扁平化UI/UE上增加了对高度信息的感知和反馈，深刻模拟了人们在日常生活中所感知对周围物体的触碰感知。例如，一张白纸就是扁平的。如果人们触碰这张白纸，那怕是最轻微的触碰，都会给这张白纸带来一些细微的变化，例如接触部位的凹陷，凹陷部位周围处的阴影等。

下面我们通过几个图来直观得了解下Material Design风格的样貌。图1所示为新的主题，分为Dark和Light两种。

图1 Material Design的主题

图2所示为新增的几个UI控件。

图2 新增UI控件

图2中所示的两个新增控件分别是RecyclerView和CardView。

在Keynote演讲中，Google向大家展示了一个旧版Gmail和基于Material Design风格Gmail的对比示例，如图3所示：

图3 旧版Gmail和基于Material Design的Gmail对比

从Keynote演讲中透露的信息来看，Material Design的目的不仅仅是换一套风格的界面，它还有试图在可穿戴设备、TV、车载系统上为用户提供更为一致性的Android用户界面和体验的考虑。

关于Material Design更多的介绍，笔者建议读者可仔细阅读它的官方介绍网站

http://www.google.com/design/spec/material-design/introduction.html。

除了Material Design，此次大会上Google还不遗余力向大家介绍了通知栏相关的改进，如图4所示。

图4 Android L中的下拉通知栏示例

图4中，下拉通知栏的界面除了采用Material Design风格外，还有几个比较重要的特征：

更多的操作，例如图中最上面的红圈①所示。
用于体现更细微信息（例如Google+在线状态）等小图标，如图中中间的红圈②所示。
能容纳更多信息的扩展通知项，如图中最下面的红圈③所示。

另外，Android L还增加一种名为MediaStyle风格的通知项以及名为“Heads up”类型的通知项，它们如图5所示：这种通知项用于控制多媒体播放，如图5所示：

图5 MediaStyle风格和Heads up类型的通知

图5左边所示为MediaStyle通知项，它用于控制多媒体播放。右图所示为“Heads up”通知项。当用户处于全屏操作时（例如玩游戏，阅读书籍等），如果收到如图所示的来电信息的，“Heads up”通知仅会弹出一个浮现与当前屏幕的通知框。这个通知框上可提供一些操作供用户选择，例如接听电话还是拒接它。由于“Heads up”通知项仅显示为一个悬浮窗口，这就避免了Activity之间的切换（在Android L之前，如果收到来电，系统会强制弹出InCallScreen界面，这时之前的全屏界面会被野蛮打断，用户体验不太好）。

最后，Android L还贴心得增加了通知信息的隐私模式，它们分别是：

VISIBILITY_PUBLIC：该通知项展示了所有信息，所有毫无隐私可言。
VISIBILITY_PRIVATE：该通知项隐藏了私密信息，仅留下对应应用程序的图标和程序名。
VISIBILITY_SECRET：该通知项可能不显示任何会泄露隐私信息的内容，包括应用程序的图标和程序名。

如图6为通知信息隐私模式的示例：

图6 通知信息隐私模式示例

图6中：

第一个通知项的模式为VISIBILITY_PUBLIC。
第二个通知项的模式为VISIBILITY_PRIVATE。
第三个通知项的模式也是VISIBILITY_PRIVATE，但是它显示的文字内容是经过修改的。在Android L中，这种处理方式叫做“Redact”，中文意思就是“编造”。

关于Android L中更多和通知栏相关的信息，请读者阅读

http://developer.android.com/preview/notifications.html。

点评：总体来说，Android L在UI风格上也跟随苹果转向了扁平化，所以有外媒调侃说这是Google在向苹果致敬。另外，Android L也将对用户体验的高度关怀体现到了系统中更为细微的地方。一言以蔽之，Android L越来越好看，也越来越好用了。

2. ART介绍

ART是Android Runtime的缩写，它是Google用于替代饱受诟病的Dalvik虚拟机的替代品。其实，ART早在Android KitKat（版本号为4.4）就已经推出，不过当时它还很不完善，所以被放到设置程序中的“开发者选项”里供一些供感兴趣的开发者使用[2]。

ART有什么好处呢？图7所示的ART/Davik性能测试对比数据相信很有说服力。

图7 ART/Dalvik性能对比测试

图7中在Nexus 5上所做的ART与Dalvik CPU性能测试中，ART的性能较Dalvik几乎有成倍的增长[3]。

ART究竟有什么神奇之处呢？根据相关资料，笔者总结其秘方如下：

采用AOT（Ahead-Of-Time，预编译）编译技术，它能将Java字节码直接转换成目标机器的机器码。
更为高效和细粒度的垃圾回收机制。

先来看AOT编译。

2.1 AOT编译介绍

AOT编译技术的目的是将Java字节码直接转换成目标机器的机器码。对比Dalvik使用的JIT（Just-In-Time）编译技术：

使用JIT时，Java程序在第一次执行某个函数时，需要先将其字节码转成机器码。
使用AOT后，Java程序在安装前，其相关代码就会转成机器码。如此，在执行过程中，就不需要花费额外的时间来做字节码转换工作了。

除了提前转换字节码外，AOT还在以下方面做了优化工作：

函数调用的去虚拟化（devirtualize method calls）。Java语言中，接口及虚函数可以很容易得解耦调用模块和实际的实现模块。但在具体执行的时候，虚拟机却要花费不少时间来查找真正的实现函数。函数调用的去虚拟化也是一种常见的优化方法，读者可参考[1],[2]来了解更多信息。
快速接口调用。
避免类初始化过程中的检查。
消除异常检查。

如前所述，AOT编译技术将在程序安装时做一些处理，相关流程如图8所示：

图8 应用程序和AOT

图8可知，APK应用程序本身的创建不涉及AOT，只是在它的安装过程中，系统将通过dex2oat工具将Dex文件转换成Linux平台上的可执行格式ELF。

另外，AOT这套处理框架可以很轻松拓展到不同的硬件平台，如Intel的X86，MIPS及相应的64位平台等。

当然，AOT在带来益处的同时也会有一些不好的影响，比如：

用于将Dex字节码转换成机器码的dex2oat过程耗时较长，这将延长第一次开机时间和程序安装时间。
dex2oat生成的ELF文件尺寸较大，这会占用不少内置存储空间。

2.2 ART垃圾回收机制介绍

ART另一项值得称道的特性就是大幅改进了Java的垃圾回收机制。垃圾回收工作主要包括两个步骤：

遍历应用程序的堆栈，枚举该应用所分配的所有对象，然后标记哪些对象还有效（这些有效的对象叫Reachable Objects）。
释放不可到达对象所占据的空间。

Dalvik时代，上述两个步骤均会造成应用程序运行过程的中断，其原理示意如图9所示。

图9 GC示意

图9中：

应用程序试图分配一个对象（由左边的蓝色方框表示），这可能会触发虚拟机做一次垃圾回收来释放一些空间（例如Java中的GC_CONCURRENT类型的回收，当堆栈使用超过一定阈值时会触发）。图9左图中的两个红色Pause阶段表示在垃圾回收过程中，应用程序会在枚举阶段和标记可到达（Reachable）对象阶段暂停工作。
GC影响最坏的情况出现在GC_FOR_ALLOCS回收时，当虚拟机没有足够空间来分配对象造成。这种回收会导致整个程序被pause，如图9中的右图所示。

GC会导致较为严重的运行性能下降，图10展示了某外媒[4]还给的一些测试数据：

图10 GC测试数据

图10中，最严重的GC_FOR_ALLOC将整个程序中断了最长168ms。如果当时这个程序正在绘制界面的话，这将导致十几帧图像数据被丢弃。

那么ART是如何优化GC的呢？总体而言有下面几个方法：

单独创建了一块名为“Large Object Space”（LOS）的空间用来保存较大尺寸的对象。
创建了一种名叫Runs-of-Slots-Allocator（RosAlloc）的分配器。这种分配器的特点是分配内存时，会采用更细粒度的锁控制。例如有不同的锁来保护不同的对象分配，或者当线程分配一些小尺寸对象时使用线程自己的堆栈，从而可完全不使用锁保护。据Google自己的数据，RosAlloc能达到最多10倍的速度提升，效果可谓惊人。
另外，为了防止内存的碎片化，ART还引入了一个名为“Moving garbage collector”的方法，其目的是清理堆栈以减少内存碎片。由于这个工作会导致应用程序长时间中断，所以它必须等程序退到后台时才能开展。

最后，ART在64位平台上也表现良好，图11所示为Google给出的一组ART和Dalvik在64位平台上的对比测试结果。

图11 ART/Dalvik 64位Intel平台对比测试结果

2.3 ART总结

结合大会给出的相关信息来看，ART极有可能是击破“Android性能不如Apple”这个观念的利剑。随着Java运行时库性能的成倍提升，一些大型应用（比如Office相关的程序）、游戏甚至视音频编辑软件都可能给用户带来更佳的体验。

ART目前还在进一步完善阶段。另外，有些依赖JNI本地调用的应用程序需要测试下兼容性。关于ART更多的讨论，请读者继续阅读https://source.android.com/devices/tech/dalvik/art.html和

http://developer.android.com/guide/practices/verifying-apps-art.html

3. Project Volta介绍

从Android 4.1（版本代号为Jelly Bean）开始，Android开发团队便力图在每个版本中解决一个重要问题。从公开的信息来看，Android到目前为止有三个Project成功发布：

随Android 4.1发布的Project Butter：用于解决UI流畅性问题。
随Android 4.4发布的Project Svelte：用于解决低内存设备的性能问题。
随Android L发布的Project Volta：用于解决系统功耗问题。

功耗问题也是Android系统饱受指摘的一个方面，虽然Project Volta致力于解决它，但笔者觉得在功耗优化方便Google还是落后于业界一些领先厂商：

有些手机厂商早就有了各自已非常成熟的节电技术，例如索尼手机的Stamina模式、三星、HTC手机的节电保护功能。有些芯片厂商还支持动态电压频率调整（DVFS）、甚至提供更为强大和智能的PMIC（电源管理）芯片。

不管怎样，Project Volta所做的努力还是值得肯定。下面来看看它具体包含哪些内容。

3.1 Battery Historian介绍

和其他所有优化工作一样，功耗优化也需要首先找到功耗的瓶颈。虽然Android系统能通过adb shell dumpsys batterystats或adb shell dumpsys power打印出电池使用情况、Wakelock占用等一些有用的信息，但毕竟这些信息看起来很不直观。所以，Project Volta首先解决了功耗信息图形化显示的问题，这就是Battery Historian工具。这个工具能将bugreport信息中和电池使用相关的数据提取并图形化显示出来。例如图12所示：

图12 Battery Historian工具

Battery Historian工具有些TraceView挺类似，通过数据的图形化显示，开发者可以很轻松了解到例如GPS开了多长时间，WakeLock占用了多长时间，CPU工作了多长时间等信息。

Historian工具虽然方便，但和一些领先手机厂商开发的更为强大的设备内诊断（In Device Diagnostic）工具比起来，它还算比较稚嫩。有些手机厂商的IDD工具还能监控设备的电压、电流、温度等更加底层和关键的功耗信息。

3.2 JobScheduler介绍

Project Volta的开发人员通过Historian工具发现了功耗一个比较大的瓶颈。图12中的红框为CPU运行的信息，从中可以发现CPU运行是一阵一阵的，每次运行都很短。这是什么原因呢？举个例子：

很多应用程序都会设置一个定时器，一旦时间到达，设备就会被唤醒，这些应用也能被触发以执行相关的操作。可是这些操作还依赖其他外界条件，例如必须连着Wi-Fi，或者连着移动网络。
由于这些外界条件不能满足，应用虽然被唤醒，但依然不能完成相关操作，所以它又回到休眠状态。

如此反复，就出现了图12中红框所示的情况。对于这种情况，应用程序本身即使非常在意功耗，它也没有办法避免。所以，Project Volta提供了一个名为JobScheduler的机制及对应的API以帮助开发者解决这个问题。

简单点说，JobScheduler其实是一个系统级的任务管理中心（对应的服务名叫“taskmanager”），应用程序通过JobScheduler API向这个管理中心池添加任务。最为关键的是，应用程序还需要设置这些任务被触发的条件，比如：

设备是否有合适的网络链接，如Wi-Fi或移动网络链接等。
设备是否空闲。
设备是否处于充电状态。
所链接的网络是否收费等。

显然，有了JobScheduler，只有那些所有条件都满足的任务才能真正被触发执行，这样就能有效避免应用程序被定时器唤醒但由于其他条件不满足又不能真正工作的情况。

3.3 Project Volta总结

从技术角度看，和前两个Project比起来，Project Volta不是特别耀眼。确实，功耗其实是OEM厂商非常关注的一个问题，他们早就在相关领域做了大量深入的研究，并提供了很多行之有效的解决方法。所以，Project Volta后续要继续深入开发的话，还需要向业界领先厂商多多学习。

4. 其他关注点

除了Material Design、ART和Project Volta之外，此次I/O大会中关于Android L还有两个比较重要的点：

一个是Google联合几个主要的GPU芯片厂商推出了Android Extension Pack开发包，其终极目标是为移动设备提供和PC机一样的图形/图像显示能力。很显然，这是一个对游戏开发者重大利好消息。另外，有了这个扩展包，似乎游戏开发者不需要再考虑底层GPU硬件的差别，而只需要基于这个扩展包开发就可以了，这也很大程度上减轻了游戏移植的工作量。
另外一个是Android Work，它是Google为满足企业级环境使用要求而做的改进。Android Work借鉴了三星的KNOX设计思路，它通过建立不同的Profile来控制不同环境下哪些应用程序能使用，哪些不能使用。作为笔者个人非常关心的企业领域，很可惜此次I/O大会中和Android Work相关的介绍比较少。笔者也查询了API变化，Android Work的功能可能集中在DevicePolicyManager中。等Android L正式发布，笔者将持续关注它。

三 Android Wear、TV和Auto介绍

此次I/O大会上，Google正式向世人推出了Android Wear、Android TV和Android Auto系统，它们分别针对可穿戴设备，电视机和车载系统。说实话，这三个系统的原型早就在各个媒体，甚至Android开发者网站（例如今年年初推出的Android Wear SDK，而Android TV更是多年前就有的）上露出过身影，当时还曾引起极大的轰动（从国内目前热度依然很高的Android智能电视即可见一斑）。那么，Google于几年后重推的这几个系统是什么原因呢？笔者分析如下：

卡位：可穿戴设备、TV和汽车和手机一样，都是与人们日常生活息息相关的设备。如果Android只占领了这四项中的一项，则将来这些设备间的交互性将大打折扣。另外，作为最大竞争对手公司的苹果也早已将iOS布局于TV和汽车，据传今年还会推出iWatch的苹果智能手表。所以，Google必须在苹果还立足未稳之时，携Android燎原之火的大好形势介入这些领域。
借着Material Design之风，顺势统一这四个平台的UI/UE。Material Design一个很重要的使命是在四个平台上为用户提供一致的用户体验。虽然Android智能手表、智能电视早就有存在，甚至有一定的普及度，但是这些设备的UI/UE都是各行其是，没有统一的标准。Google必须在这些混乱还未伤筋动骨前解决这个问题，否则，Android的开放只会造成无序和混乱。这一点，相信Google已经从Android手机领域中汲取教训了。

此次I/O大会上，关于Wear，TV和Auto方面的介绍主要集中在应用开发上，而关于这些系统的特性则介绍得较少。下面我们分别介绍它们

3.1 Android Wear概述

先来看Wear，从这次大会的情况来看，Goole似乎将可穿戴设备的重点放在了智能手表上。显然，无论从法律法规还是使用习惯来看，智能手表都比Google Glass更容易被大众接受。本文下面所指的可穿戴设备都特指智能手表。

由于智能手表屏幕实在太小，所以Google要求应用通过卡片式的界面来与用户交互。如图13所示：

图13 Wear上的应用界面

从消费者角度看，智能手表给他们提供的信息将通过一种名为“上下文信息流（Context Stream）”的方式来展现，Context Stream包含了一组卡片式视图，每个卡片视图表达一件事情或一条信息（比如闹钟提醒，来电通知等）。用户只要在智能手表上左右/上下滑动这些卡片，就能浏览相关内容。

当然，为了达到“解放双手”这一终极体验，智能手表还将支持Google的语音服务，用户只要对着智能手表说出关键词，就能触发相关应用的启动。

最后，作为Wear还能和手机等设备相连，系统为此提供了三个层次的API：

和其他设备相连的Node API，一个Node应该就是一个设备了。
用来在已连接设备间传递消息的Message API。Message是一种有固定格式的数据。
用来在已连接设备间传递原始数据的Data API。有些数据无法通过简单的Message来表示，所以Wear支持传递原始数据。

注意，这些API底层都需要Google服务的支持。

点评：Wear看起来很美好，但从目前媒体反馈的情况来看它还有很多问题要解决：

从用户体验情况来看，如果通知的信息较多，用户就得不断滑动屏幕才能找到最终的目标信息。读者可以想象下这会是一种什么样的感觉。
智能手表屏幕很小，用户如何购买那些需要付费才能使用的应用？这个问题目前还没有解决，所以Play Store上发布的针对Wear的应用都免费。
Android Wear这个系统或许很出色，但智能手表这个设备本身是否会真正吸引用户？例如外观，佩戴体验，功耗等。从现场情况来看，在座的与会者显然更钟情于Moto 360的原型表盘设计。所以，Google是否会考虑像推出Nexus手机一样也来设计一款足够吸引眼球的Google Watch呢？

3.2 Android TV概述

再来看TV，图14所示为一个示例：

图14 Android TV示例

此次Android TV引入最大的变化就是：整个操作界面将悬浮于正在播放的视频之上。这样，用户无需停止当前视频的播放，就能操作或控制TV了。说实话，笔者相信国内某些智能电视的用户早就体会过类似的事情了。但更甚一筹的是，Google还解决了遥控器过于复杂的问题。此次Android TV的遥控器只有最多8个按钮，如图15所示：

图15 Android TV遥控器

当然，遥控器能做到这么简单是因为Android TV中应用程序将使用几种最基本的layout风格，如图16所示：

图16 Android TV基本Layout

显然，如果应用的UI都采用图16所示的风格的话，Android TV遥控器就能做到只需上下左右这四个基本的导航按钮了。

另外，智能电视上还存在一个比较大的问题就是各国/地区直播电视的制式互不相同，而且同一个地区还有不同的运营商，其电视信号的接入方式也不尽相同。这个问题的直接后果就是每个电视用户家中都有数个遥控器。对于追求极致的Android TV来说，此问题是绝对不能容忍的。为此，Android TV设计了一个输入框架来统一TV上的输入设备，如图17所示：

图17 TV输入框架示例

无论电视源输入是有线信号还是IP数据，最终都会归结为TV的Unified输入。这样，用户在如图18所示的界面中就能选择并收看实际上是来自不同输入源的电视节目。

图18 Android TV中选择电视信号

最后，为了达到较好的用户体验，Google对Android电视的硬件也提出了一些要求：

至少1G内存和8G闪存
支持WiFi或以太网
支持蓝牙BLE
支持Widevine Level1和Playready DRM
另外，Android TV将兼容Google Cast

最后，为了方便TV的开发者，Google对此次大会的部分与会者还赠送了一个名为“ADT-1”的盒子用来充当真实的Android TV设备。

3.3 Android Auto概述

根据I/O大会上介绍的消息，早在2005年Google就已经着手开展与车载系统有关的研究了，其产品经过多年精心打磨，从而得到今天的Android Auto系统。图19为Android Auto的示例。

图19 Android Auto示例

Android Auto系统中：

手机通过USB线和汽车中控屏幕相连。采用USB连线的原因一个是USB有着较高的数据传输速率，另外一个就是汽车还能通过USB线为手机充电。
手机和中控屏幕通过USB线传输Audio、Display、Sensors和Input数据。
当手机连接上中控屏幕后，手机进入汽车模式（Car Mode），手机上相关应用的图形/图像将投射到中控屏上显示。也就是说，Android Auto系统中，中控屏只是一个大的显示器和触摸屏罢了，其显示的内容其实来自于手机。为什么这么设计呢？这是因为车载系统更新换代速度往往较慢，而智能手机却能很方便得更新应用程序，甚至更新系统。通过投射方式，用户就能将和手机上一些最新的体验很轻松得带入自己的爱车当中。

目前，Android Auto对应用程序只开放四种类型的API，分别是Navigation、Messaging、Voice以及Notification，并且要求手机必须集成Google的Car Service和Play Service。另外，受相关法律法规限制及出于避免驾驶员分心的考虑，一些车载传感器等和汽车有关的信息都不会对应用程序公开。

Android Auto的界面比较简单，图20展示了两个例子：