The future of Android in vehicles -

The future of Android in vehicles

Editor’s Note:  The authors describe the design challenges to incorporating the Android platform in automotive infotainment, and suggest some solutions.

Android was initially geared for smartphones and tablets but is quickly expanding into automotive and embedded markets. With its open-source flexibility, powerful content delivery system, and consumer device ubiquity, Android is a tempting choice for center stack designs, but presents significant challenges for designers. This article discusses these benefits and challenges, highlighting the importance of marrying in-vehicle infotainment bells and whistles with safety and security mechanisms.

Modern Automotive Electronics
One of the first computer systems in an automobile was the 1978 Cadillac Seville’s trip computer, run by a Motorola 6802 microprocessor with 128 bytes of RAM and two kilobytes of ROM. The printed source code could not have occupied more than a handful of pages. In contrast, today's automobiles contain massive aggregate compute power and millions of lines of code. Examples of computers embedded within a modern automobile are shown in Figure 1 :

Figure 1: Embedded computing within the modern automobile

Automotive electronics architecture is being driven by the demand for better capabilities and consumer electronics experiences in the car, the digitization of manual and mechanical functions, and the interconnection of our world. The infotainment system is the most complex component of all, running sophisticated consumer operating systems and application frameworks on top of multi-gigahertz multicore microprocessors.

Why Android?
The expansion of capability in infotainment systems has not been without pain. In 2012, for the first time in its 26-year history, the J.D. Power Auto Quality study found that the infotainment system is now the biggest source of problems in new cars. In particular, the study identified speech recognition (or the lack thereof) as the most common complaint. A compelling advantage to Android is that it has a wide variety of excellent voice recognition solutions, driven by the increasing popularity of speech-driven mobile device operation.

Beyond the benefits of intelligent voice recognition, Android is the most popular and fastest-growing mobile operating system (OS) (two-thirds of worldwide smartphone shipments), automotive OEMs see Android as the means to provide the best possible multimedia experiences.

Android provides standardized interfaces for accelerated graphics, audio, wireless networking, Bluetoothtechnology, USB, and more, enabling applications to easily harness the power of these hardware facilities. OEMs see Android as a means of leveraging consumers’ familiarity with mobile devices to improve the automotive experience.

Another advantage of Android is its open-source licensing model. While closed source operating systems publish APIs for app developers, they do not allow the base frameworks to be modified and expanded. This is especially critical in the automotive world, where OEMs need to differentiate and support automotive-specific behaviors and constraints. Android’s frameworks and hardware abstraction layer employ the flexible Apache license, which permits modification of the source code without requiring the developer to release those code modifications or their associated intellectual property rights.

The availability of the Android open-source infotainment platform comes at a time when OEMs are taking more control over the digital infrastructure in cars. The traditional model of outsourcing the entire infotainment system to Tier-1 component suppliers is being replaced (to varying extents) by some OEMs who choose the operating system, development environment, and microprocessor platform, and some even perform a significant amount of the software development. Tier-1s are asked to build hardware and provide application and driver work, but the OEM owns the architecture. Android provides the control that OEMs require in this new world.

Challenges with Android in the Car
Given the inflow of consumer complaints about infotainment systems, OEMs are justifiably concerned with the reliability, stability, and security of Android. Android’s extremely large source code base coupled with its open source development model results in extreme churn – literally thousands of edits per day across Android and its underlying Linux kernel. This guarantees a steady flow of vulnerabilities. A quick search of the U.S. CERT National Vulnerability Database turns up numerous vulnerabilities of varying severity. Here is a sampling of the worst offenders:

  • CVE-2012-4190: allows remote attackers to cause a denial of service or execute arbitrary code
  • CVE-2011-0680: allows remote attackers to read SMS messages intended for other recipients
  • CVE-2010-1807: allows remote attackers to execute arbitrary code
  • CVE-2009-2999, -2656: allows remote attackers to cause a denial of service (application restart and network disconnection)
  • CVE-2009-1754: allows remote attackers to access application data
  • CVE-2009-0985, -0986: buffer overflows allow remote attackers to execute arbitrary code

We point out these particular vulnerabilities because they fall into the highest severity category of remote exploitability. These types of Android and Linux vulnerabilities are used by hackers to root Android phones and tablets.

Driver/passenger safety Another concern with Android is driver/passenger safety. Automotive electronics architecture is in the midst of a major trend reversal: instead of adding more and more processors for new functions, disparate functions are being consolidated into a smaller number of high performance multicore processors in order to reduce size, weight, power, and component/wiring cost. Processor consolidation is leading safety-critical systems to be integrated with infotainment. For example, OEMs are looking to host real-time clusters, rear-view cameras, and Advanced Driver Assistance Systems (ADAS) within the center stack computer (Figure 2 ).

Figure 2: Mixed criticality Android infotainment system

Next-generation Android infotainment systems must ensure that applications and multimedia do not interact in unforeseen ways with safety functions, posing a risk to passengers.

There’s another, perhaps less obvious, problem with the traditional stovepipe approach of separate computers for each function: ultimately, this approacy stifles the passenger experience. The cluster can only display navigation information if the requirements for the cluster and infotainment boxes include such an information flow. Once the boxes are deployed, other interactions, potentially integrating and improving the overall experience of both components, become logistically difficult or infeasible. If multiple functions can run on a single box, physical wires become virtual wires; software improvements affect a single box instead of multiple boxes; performance and flexibility of communication is drastically improved.

The consolidation trend is aided by next-generation performance-efficient multicore processor platforms such as the OMAP 5 platform from Texas Instruments Incorporated (TI), with a dual-core, power-efficient ARM Cortex-A15 processing architecture and a wide range of integrated I/Os, such as wireless networking and multiple graphics accelerators. 

The Google handicap Another barrier to adoption of Android ininfotainment systems is the lack of support from Google. Google has anextensive validation and approval system for the use of Android in highvolume mobile devices, and this approval is required in order to bundleGoogle’s proprietary applications, including Google Maps and GooglePlay. To date, Google has not demonstrated interest in validatingversions of Android for automotive infotainment, leaving automakersfeeling like they are using a homegrown OS rather than a Google OS.

Becauseof Google's lack of support, Android APIs are ignorant ofautomotive-specific behavior and I/O. Android has no concept of CAN,MOST, Ethernet AVB, or any other automotive network technology. Androidhas no concept of disabling certain functions to avoid driverdistraction. Adapting Android to the automotive environment impliessurgery. It may take some time for Google to accept and implant thesenew limbs and vessels.

An intellectual property and data rightsissue also looms over Android. If OEMs make use of Android APIs fornavigation, it is likely that the OEM would want to exploit the data todrive other telematics services such as remote assistance. Thisaggregated knowledge is valuable, and the OEM may want exclusiveownership of location data gathered in its cars. Unfortunately,ownership of this data is nebulous; as stated in the Google SDK termsand conditions: “if you use any API to retrieve data from Google, youacknowledge that the data may be protected by intellectual propertyrights which are owned by Google.”

One of the biggest advantagesof Android over other popular multimedia infotainment operating systemsis the deep integration of the app store. Android provides APIs foraccessing the app store, integrating advertising for increased revenueopportunities, and over-the-air updates for apps. However, because ofthe license restrictions mentioned earlier, Google Play may not beavailable in “AutoDroid.” In addition, OEMs most likely will want theirown app stores in order to control the user experience and encourage (orenforce) the use of OEM-approved applications. Google’s SDK does notcome with support for creating and using a third party app store, soOEMs are faced with developing their own infrastructure and/or utilizingthird party app store creation services.

Field upgrade  Anotherdeployment problem facing OEMs is field upgrade. Imagine a car on theroad today running Android 2.2 (“Froyo”) in its infotainmentsystem. Your Android-knowledgeable friends coming along for a ridechuckle as they pull out their Jelly Bean or Key Lime Pie phones. ButFroyo was released in 2010, young for an infotainment system on the roadin 2012! Adopting Android will drive OEMs into a more aggressiveupgrade strategy to avoid appearing outdated. While Android mobiledevices support firmware over-the-air (FOTA) updates over carriernetworks, these OTA systems are carrier and device specific, not part ofthe Android open source product and SDK. If an OEM wants to supportFOTA, custom work is required.

Meeting the Challenges
OEMscannot depend on Android to control all aspects of next-generationinfotainment systems. Android cannot boot fast enough, cannot guaranteereal-time response for protocols such as CAN, and is not reliable andsecure enough for safety-critical functions such as ADAS and integratedclusters. OEMs need a system architecture in which Android and itsapplications can peacefully coexist with real-time, criticalapplications.

A number of OEMs are looking to virtualization asthe solution to next-generation infotainment system architecture. With aspecialized form of real-time hypervisor, the platform can host Androidwithin a virtual machine alongside, but safely isolated from,lightweight applications that use open standard APIs to performreal-time, safety, and security-critical functions.

One exampleof such a hypervisor is Green Hills Software's INTEGRITY Multivisor,built upon the INTEGRITY separation kernel, used extensively inautomotive infotainment and other mission-critical applications since1997. With this kind of virtualization solution, the infotainmentcomputer can achieve boot times measured in milliseconds to handleinstant-on tasks such as responding to CAN messages and bringing up therear-view camera. With a platform that enables this mixed criticalityarchitecture, OEMs can reduce size, weight, power, and cost in theelectronic infrastructure while taking advantage of the latest Androidbells and whistles.

Applying this hypervisor architecture to theaforementioned system, consisting of the main infotainment OS andsafety-critical applications for rear-view camera and driver informationcluster, results in the architecture shown in Figure 3 :

Figure 3: Virtualization architecture for Android infotainment systems

Inaddition to safety apps, security-critical functions can also bepartitioned from Android, enabling a form of security retrofit to anotherwise vulnerable environment. For example, the transmission ofsensitive information over vehicular networks and storage of privateconsumer or OEM data within Android’s storage system can be hardenedusing the hypervisor as shown in Figure 4 :

Figure 4: Security retrofit to Android using virtualization

TI’s OMAP 5 processor is an excellent example of an automotive system-on-chip, well suited toenabling Android in next-generation automotive systems. The OMAP 5processor’s power-efficient, dual Cortex-A15 cores, with ARMvirtualization extensions (ARM VE), assortment of connectivity andcommunications peripherals, and multiple graphics and multimediaaccelerators enable an uncompromising Android experience concurrentlywith the instant-on and real-time, safety-critical workloads hosted bythe hypervisor.

Many of the other automotive requirements, forexample processing of CAN messages in automotive-aware Androidapplications, are easily handled with some simple augmentation of theAndroid environment. CAN messages can be encapsulated using customhardware abstraction layer APIs connected to the underlyingcommunications driver. Alternatively, the hypervisor can convert CANinto a virtualized device that Android already understands and protectthe critical CAN peripheral from direct access by Android. In the end,CAN messages are just simple data structures.

Android has apowerful standardized sensor capability, with support for acceleration,magnetometer, temperature, gravity, gyroscope, touch proximity, andlight detection. Automotive app developers can use these standard APIsto detect conditions in which certain applications or services should beinhibited. Android’s standard vibration and sound APIs can be used toprovide the driver with haptic and audio feedback when visualization isdiscouraged. In a virtualized environment, the hypervisor must becapable of safely multiplexing peripherals that are needed both by theAndroid environment and critical applications.

Setting up an OEMapp store is not as difficult as it may sound. Android providesfoundational APIs for remote communication and applicationinstallation. Creation of the app store itself can be accelerated byworking with white label app store providers, such as SlideMe andAptoide, who have done a lot of the heavy lifting. Furthermore, Androidconsultancy organizations such as the Mentor Graphics embedded softwaregroup are ready to help.

Android represents atremendous opportunity for automotive OEMs to leverage the latest andgreatest consumer electronics technology for an enhanced driver andpassenger experience while providing a maximum level of control andcustomization. OEMs must be prepared to develop in-house Androidexpertise to bridge the gap between what the open source Androidecosystem provides and what is practically needed to develop acomprehensive infotainment system and cloud-based app store and servicesenvironment.

Automotive electronics require a systems softwarearchitecture that enables an Android infotainment stack to be deliveredwith the reliability, safety, real-time performance that OEMs andconsumers demand, particularly in light of the consolidation trend. Thecombination of virtualization and powerful multicore processors can helprealize this vision.

David Kleidermacher , ChiefTechnology Officer of Green Hills Software, joined the company in 1991and is responsible for technology strategy, platform planning, andsolutions design. He is an authority in systems software and security,including secure operating systems, virtualization technology, and theapplication of high robustness security engineering principles to solvecomputing infrastructure problems. Mr. Kleidermacher earned his bachelorof science in computer science from Cornell University.

Brad Ballard is Audio and Infotainment Product Line Manager, Texas Instruments Incorporated (TI).

1 thought on “The future of Android in vehicles

  1. Vehicles have partitioned system buses for safety reasons, making many of these fears moot.

    Clearly you don't want Android running any of the body/safety electronics or the engine electronics. It would be unacceptable for a software crash or long boot del

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.