mARTini

Introduction

It is no surprise that automotive infotainment systems are evolving, yet it is even less of a surprise that tech giants like Google and Apple are taking a major part in this change.

With a quick internet search on the market offering (by googling of course) you can see the vast number of titles referring to the main products in this area developed by those two players – Android Auto by Google and CarPlay by Apple. Naturally, Android Auto works for Android phones and CarPlay is customized for iPhone users. A review article at Forbes Wheels reads: “Your New Vehicle Should Have Apple CarPlay Or Android Auto—Here’s Why”. Here we have a choice, either not having these additions to our car infotainment system or to choose one of the two listed, with no alternative. Next step is, obviously, to support the OS natively in IVI systems. If we want to keep up with these infotainment trends, what choices do we really have?

Furthermore, when we talk about the global market share of the two operating systems above, according to StatCounter (presented below), Android is clearly winning the competition. Based on ABI Research’s recent whitepaper, 36 million new vehicles will be shipped with Android infotainment systems in 2030. This makes it hard to remain neutral towards implementing this widely used operating system in the automotive industry.

Android users often want to use the same familiar services while they are in the car as when they use their phones, posing a great challenge for car manufacturers. OEMs need to be highly responsive to the Android market demand and find a suitable solution for this. The Chinese market is already adding pressure by pushing their OEMs to fully transition and replace the Head-Units and be able to integrate Android completely.

Source: StatCounter Global Stats – OS Market Share

Although it is inevitable that Android becomes a common part of a car infotainment system, many OEMs are still not ready to make this transition “over-night”. They need to find the formula that provides a win-win solution – to stay competitive and, at the same time, stay authentic in their own transformation.

Most OEMs already have an in-vehicle infotainment (IVI) solution in place which is mostly based on Linux. For them it is convenient to be compliant with Android services and capabilities; still an instant “switch” to Android OS brings serious challenges for OEMs. Losing their unique identity due to a different UI and corresponding UX of the Android platform is one of the considerable downsides if looking from a long-term perspective. OEMs have been building their brand and recognizable appearance for years and are reasonably careful with compromising the signature of their current IVI solution. However, Android is a welcome add-on and will gradually become an integral part of any IVI system. That is why OEMs should be able to already benefit from it, even though they choose to preserve their unique user experience.

Hybrid solutions offer both, keeping the OEM’s own footprint with Linux-based architecture as well as allowing the running of Android apps and being open to this fast-evolving market.

There are multiple approaches to achieve this hybrid solution:

1. External HW
2. Hypervisor
3. Container

In this whitepaper, we will focus exclusively on Containerized Android.

What problems does Containerized Android solve?

OEMs want to enable Android-based apps within their IVI solution, but are not ready to fully transition to Android OS, owing to certain disadvantages such as lack of differentiation in user experience as well as potential need to rewrite many features already developed and proven on existing systems.

Containerized Android enables OEMs to retain competitiveness on the market through enabling Android apps to run on their in-car infotainment systems, while keeping their own identity by using the same underlying OS as before. It integrates Android in legacy Host OS and enables Android features within an existing Head-Unit OS (usually Linux-based). Therefore, the overall Head-Unit SW is kept as it is, with the Containerized Android adding functionalities to the host system.

The main goal of the Containerized Andorid is to design and develop a system solution for running both Android and Linux IVI applications in the same system environment.

Containerized Android enables running Android applications in a controlled environment within Linux operating system. Likewise, Hypervisors are a widely accepted solution in the automotive industry, used for developing Android and Linux on the same SoC. Although Hypervisors handle major functional safety Automotive requirements for the two integrated operating systems, the solution introduces restrictions in static memory distribution across multiple guest operating systems. One of the main target points of the Containerized Android solution is to resolve the resource bottleneck. Namely, it is possible to dynamically allocate system resources (CPU, RAM, GPU). Consequently, it is allowed for both operating systems to have the capability of executing more demanding applications, or to optimize the resources accordingly and therefore achieve hardware cost reduction when compared to hypervisor, without performance impacts

Can Containerized Android support demanding features (e.g. multi display)?

Having multiple displays is a popular trend in today’s Automotive Infotainment systems. A typical use-case consists of a main Head-Unit display, with additional two displays in rear seats, but the number of screens is often even higher.

Containerized Android supports integration with a multi-display environment. An example of integration of multi-screens is on Qualcomm SA8155 with the following specifications:

• Supports multiple display instances,
• Multi touch support for different screens,
• Android Audio/Video projection,
• Inputs from user to Linux and Android (touch, jog shuttle, mic, Linux keyboard…),
• Multimedia, voice, etc.

Since it is not of interest to allow duplicated interfaces on both Android and Head-Unit OS, all applications from both systems shall be managed from Head-Unit system. To integrate our solution into the Head-Unit and keep the two systems connected and efficient, we need to address certain aspects:

1. Make whatever is rendered by Containerized Android visible – this is accomplished via host system adaptation module called Container Manager. This module is implemented to bridge Android graphical, video, audio, input and GPS layers.
2. Manage the interfaces in the vehicle – access to all the interfaces in the car (touch screen, buttons, climate control, GPS, Media, and other sensors) from the Head-Unit is exposed to the Containerized Android module.

Architecture

Containerized Android is a solution based around utilizing Linux Container technology to enable co-existance of both Linux-based Head-Unit and Android OS on same SoC. Solution is platform independent, with the Board Support Package (BSP) implemented to support Yocto Project build system.

Key components:

Architecture workflow:

At the start of the system, the Containerized Android will be present in the background. Inter-OS communication modules are automatically initialized (Graphics subsystem, Audio, GNSS, Input). At startup, no Android application exists in the system. It must be chosen by the end-user which Android app is required. An application installation request is initiated using a special implemented Client API. The installation of the application onto the Containerized Android system is done through Container Manager. Likewise, when the application needs to be started, a start request is initiated using a custom implemented Client API. The application is then started in the Containerized Android. An activity window is presented on the Linux host OS Wayland display server, with support for touch input events.

Use cases

In general, there are so many Android compatible apps that are “must have” for the OEMs to provide familiar service to their users. There is no difference in why this or that app is available on your mobile phone while waiting for an appointment and not be available in your car while moving from A to B or standing stationary. If we say that it is normal to switch from a laptop to a phone that are familiar in appearance and user experience, then there should be no difference in being able to switch from one of these devices to IVI. This availability only expands the usability of those services to one of the most common ways of transportation in modern living.

Media

Media usage, including services like Netflix, and YouTube (just to name a few), represents the most challenging use case. At the same time, video streaming is one of the most used entertainment services nowadays. Users want to have access to it wherever they go, which inevitably includes transportation and, in most cases, a personal car.

Gaming

Gaming at home, gaming in a park on a mobile phone, gaming with friends, in person and virtually. Gaming has become one of the most popular every-day forms of entertainment. When you finally reach the next level, you want to have the option to see what is next. And if one needs to spend 10 hours in a car, to have this option is priceless for the user. At some point, it might even become a criterion while buying a car.

Chat

Exchanging thoughts through funny images, emoticons, gifs, and videos is a very appealing way of communication. Chat services such as WhatsApp, Skype, or Viber have become an almost mandatory tool for fast and easy communication. This service should support the need for continuous “talks” and exchange of ideas and thus should always be available and on hand for the user.

How to balance to performance and integration

Like in every engineering problem, with container approach there is a tradeoff that needs to be addressed. The tradeoff we are seeing here is between complexity of integration and performance. To be able to utilize all the specific hardware resources like GPU and codecs that will enable a significant boost in performance a platform specific integration is necessary. This is why in our architecture we are able to support both models depending on customer needs:

• Full graphics acceleration – integration with platform GPU and codec API to achieve maximal performance

• Simple graphics solution – full software implementation of graphics renderer and codes for minimal hardware dependency and fast deployment

Who will use this product? Target audience

OEMs – Licensing of our Containerized Android solution adds Android capabilities to existing OEM IVI. With our solution, OEMs have the possibility to continually upgrade its system, and stay in touch with the life cycle of Android based applications.

Software delivery to OEMs:

The following software components shall be delivered to the OEM, which are necessary for adding Containerized Android support on an already present Head-Unit OS:

1. Containerized Android images (first version for Android Q)
2. Container Manager application
3. Client/Server communication library – with supported functionalities:
   1. install
   2. uninstall
   3. list
   4. start
   5. stop
4. User Manual (with product description and environment setup steps)

NOTE: It is required by the OEM to have a Store application, in which an option exists to download Android applications. Both Android and Linux Store applications are supported, and both use-cases shall be covered in the environment setup part of the User Manual document.

Why is it important (the big picture)?

A solution enabling the usage of the Android based apps should have more than a single alternative to reduce the barrier to entry for the OEMs that have certain concerns. The Android app market is huge, and it is a win-win situation for the app providers as well as OEMs to stay connected. Users will be able to have the full experience regardless which car they choose. Being compatible with Android services should not be a selection criterion but a feature that every car maker can offer to its customers without compromising on brand identity.

Android compatibility with Containerized Android

The Android Q official release version was the starting point in implementing the Containerized Android. At current implementation state, the Android Compatibility Test Suite (CTS) has run only on inter-OS integration modules (Graphics, Audio, Input, GNSS) of the Containerized Android. Tests show normal system behavior, like any other Android compatible Device. Future work shall include widening the CTS selection and performing detailed verification of the Containerized Android Device.

Security

Major requirement in today’s automotive software is security. Regarding the Containerized Android product, security is taken into consideration. On one hand, only indirect access to Platform OS device drivers is supported from the Containerized Android, which is achieved through implemented Container Manager component. On the other hand, a separate user configuration is made to have restricted access to Android system partitions. A custom checksum functionality is implemented to support Android Verified Boot (AVB) inside the container runtime environment.

Update support for new Android versions

We are committed to support Android evolution, at any point in time R&D is done on 2 latest Android versions and 2 different hardware platforms. The A/B partition layout will be supported, enabling two copies of Android partitions. The update shall be performed under specific terms, described in the User Manual of product delivery. The update process shall first start in the inactive partition, which will then trigger a system restart. After restart is finished, the before inactive Android partition shall be activated, containing the updated version of the Containerized Android system.

mARTini demo on NXP i.MX 8QM

Demos

WE’VE HOSTED A MARTINI WEBINAR. TO LEARN MORE, GET THE SLIDES & RECORDING: