Developing Android-driven applications for automotive infotainment

December 1, 2012 OpenSystems Media

3Google's Android mobile Operating System (OS) has quickly become the dominant platform for smartphone devices. Can Android be equally effective in the In-Vehicle Infotainment (IVI) sector? Despite Android's many functional advantages, software developers must take a careful look at Android's strengths and weaknesses before adopting the OS in modern IVI systems.

Developers today can make a strong case that Android is now the most successful portable OS of all time. In terms of recent smartphone sales, according to research firm IDC, Android devices represent a 68 percent share of the global market (quarter ended September 2012). This compares to a 17 percent market share held by Apple. Within 12 months it is expected that more than 1 billion Android devices will be in use – an achievable goal considering that nearly 700,000 new smartphones are activated every day. Easy access to software and development tools for Android means just about anyone from an individual engineer to the largest R&D department at a large corporation can get involved.

For corporations selling online services, it’s almost a limitation not to have an appropriate Android smartphone app. During the past five years, user expectations have migrated from seeing a good website to seeing a good mobile website to having an Android or iPhone app available. According to AOL Tech, the download rate for Android apps in 2012 is 1.5 billion installs per month, with a total of nearly 20 billion installs to date.

Unfair to compare

It was inevitable that individuals who own both a smartphone and a vehicle equipped with an IVI system would compare and contrast the two. The functionality of a typical infotainment system has evolved in the past 10 years, restricted by the lengthy development cycles of automakers and their traditionally conservative approach to product development. Quality and reliability are paramount, as well as the overwhelming need to keep costs low to ensure the final product stays competitive.

At the recent Paris Motor Show, several automakers announced their latest models embodying the concept of the always connected automobile. One such system was Renault’s Android-based R-Link infotainment system featuring built-in Android apps such as navigation, multimedia, and phone support via an online store for Renault-approved apps. Despite these and other IVI enhancements, any driver today can look at a contemporary smartphone and find much more functionality and personalization on that device compared to an IVI system. Carmakers are becoming increasingly desperate to incorporate this level of functionality and flexibility into a vehicle without compromising its safety and security. Using Android, there are several ways to accomplish this endeavor, each with its own set of advantages and disadvantages.

Bring Your Own Device (BYOD) to your vehicle

If the Android smartphone can be considered the ultimate infotainment device, then why not have it connected inside the car? This is the approach taken by the Car Connectivity Consortium, an industry alliance established to allow smartphone screens to be displayed on the infotainment head unit. Several infotainment platform providers, including Mentor Graphics, offer this approach, whereby the head unit acts as a thin-client display, with apps running directly on the smartphone. Connectivity is provided through USB cable today, but Wi-Fi connections are emerging. Bluetooth 3.0 may also offer sufficient bandwidth for video streaming between smartphones and IVI systems.

The advantage of this approach is that the phone connectivity technology will not become obsolete as the car ages, which is an important factor given that the typical smartphone enjoys a higher refresh rate over its lifetime. The concept of random IVI software updates is seen as too risky for the more permanent car-based system; OEMs want to keep the process under their strict control. Looking 10 years ahead, this means that the infotainment system can still be current and relevant because its functionality is based on the smartphone at the time.

This approach also presents a cost advantage, as the permanently fixed infotainment system costs less for an OEM or Tier 1 developer to design and maintain. Another benefit is related to shared or rented vehicles – the smartphone immediately personalizes the vehicle to which it is tethered, without needing to learn a new user interface every time. One example showing the advantages of integrating a smartphone into the infotainment system is Android car mode, which turns an Android phone into a better driving companion by providing quick access to key applications such as GPS navigation, voice-activated commands, and a phone’s contact list.

The main disadvantages of allowing smartphone screens to be displayed on the infotainment head unit are loss of control and marketability of the infotainment system as a car feature. High-end automobile manufacturers are now differentiating themselves through the sophistication of an infotainment system; they are not willing to pass that advantage over to phone makers. There is also the unknown security risk lurking in terms of the potential for someone to hack into the vehicle system via a smartphone.

Considerations for building in an Android OS

Many designed-in infotainment systems such as the Renault’s R-Link build Android directly into the vehicle and pre-load a number of approved and tested apps. This offers a pre-built, tested, state-of-the-art infotainment system to a prospective car buyer. The idea here is that it’s now possible for the vehicle owner to download additional Android apps from an online store managed by the manufacturer. The Android OS is kept isolated from other vehicle functions and apps are only offered from manufacturer-approved repositories to help protect the system from malware. However, as Generation Y Android users start to dominate the car buyer population, they will want the freedom to download their favorite apps and won’t be happy with a pre-defined mix decided for them.

Looking at this from an OEM perspective, adopting Android as a base OS poses a few significant business risks. Some OEMs are nervous about the omnipresence of Google as the owner and licensor of the Android OS platform. Because Google manages the release schedule and content of Android, many automotive strategists are wary about Android changes affecting their product release cycle. What would happen if the license or terms of use suddenly changed?

The original Android OS was designed exclusively for mobile smartphones, and it must be modified to handle the wide variety of audio streams in the vehicle with signals coming from reversing sensors, radio, DVD player, navigation, phone, and external sources. The middleware in Android that covers audio stream routing has proved difficult to modify and re-test; the intended infotainment system has to link in at several points including the audio flinger (mixer providing a single output at a specified sample rate), underlying audio hardware, and audio manager. Some developers are questioning why they should commit to the technology when it’s possible to dock a smartphone into the vehicle.

Embedded Android architectures

Developers can choose from several possible approaches to implement Android into a vehicle. Some vehicle manufacturers use Android as the core OS for the infotainment system, deeming that it’s secure and mature enough to fulfill this role. For designers who are not as bold and want to stick with Linux, Android can still be included as a guest OS in a “container” (see Figure 1). Using the Linux Container (LXC), resources can be assigned by the Linux host to the Android guest, which includes memory available for apps, access privileges, services available, and interaction with other domains. The container is intended to be a secure environment, so users can potentially download entrusted apps into this area.

21
Figure 1: When running Android in a Linux Container, privileges and permissions can be tightly controlled.

Another technique for including Android in an IVI system is to use a hardware or software virtualization layer (see Figure 2). In this scenario, each OS or domain runs on a dedicated virtual machine, and the hardware resources available from the underlying host platform are shared. Communication is allowed in a controlled way between the different domains, and boot-ups may be independent, allowing safety-critical features running on a dedicated domain to be available more quickly than the infotainment or Android systems.

22
Figure 2: Android and Linux can run simultaneously on a virtualization layer or hypervisor.

Several hardware platform providers provide isolated domains in hardware. Software virtualization is available using proprietary software from providers such as SYSGO, OpenSynergy, and Open Kernel Labs. These virtualization layers consume a small amount of overall resource (typically 1 percent to 4 percent) and allow a high degree of domain isolation and safety.

In a few years, all drivers will expect their vehicles to be permanently connected to the Internet. This will allow access to cloud data services, telematics, video and audio streaming, and apps download. It is no longer a question of if this happens, but rather when all of this becomes available to the general public. The explosion of Android in smartphones has ensured that Android apps will need to be accessible in vehicles, and users will decide if these are built in or accessed via a BYOD solution.

Andrew Patterson is business development director for Mentor Graphics Embedded Software Division, specializing in the automotive market.

Mentor Graphics Embedded Software Division Andrew_patterson@mentor.com www.mentor.com

Follow: @mentor_graphics Blog Linkedin

Andrew Patterson (Mentor Graphics)
Previous Article
Heterogeneous system architecture: Multicore image processing using a mix of CPU and GPU elements
Heterogeneous system architecture: Multicore image processing using a mix of CPU and GPU elements

Image processing is computationally intensive, requiring immense resources in CPU and memory throughput. Pa...

Next Article
Embedding security into data management
Embedding security into data management

Securing data is becoming more critical and more difficult to accomplish as embedded application developmen...