AP-IO

Introduction & Goal

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; 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.

With the external HW OEMs can maintain their existing IVI solution and appearance and still be able to utilize Android compatible apps that are filling the market continuously.

What problems does this product solve? How?

OEMs want to implement Android-based apps into their IVI solution, but are not ready to fully transfer 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.

Our product 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.
AP-IO is a communication framework between the head unit OS and Android that enables Android features with an external HW module. It takes care of projection of Android graphics/video/audio to the Head Unit and exposing the head unit interfaces to Android. It is the extension of the existing system, mainly Linux. Therefore, the overall SW is kept as it is, with the external HW module bringing Android functionalities to the host system.

The Google Play store with dedicated Android applications is filling very fast. Android systems in the modern vehicles need to be continuously updated to the latest requirements of such applications. However, this has shown to be very challenging in the automotive industry. As Android is updated each year, it requires expanding the SoCs as well as the RAM consumption. Therefore, the life cycle of the devices based on the Android (smart phones, smart tv, etc.) is only approx. 3 years. However, the head units require 3-5 years of development efforts and once in SOP need to last additional 10-15 years of life. It is clear that having Android on the head unit, at least with the currently very high HW cost, isn’t a sustainable solution. This is where external HW module comes in handy as it can be replaced with more advanced HW easily during the vehicle life cycle and therefore keep the HW and SW fresh.

Our AP-IO communication framework enables communication between external HW and the legacy system (mainly Linux) through a single USB 3.0 external HW system and thus is easily integrated into the host system. Our solution allows on the initial solution to remain, while enabling the Android functionalities for the end user. We are always aligned with the latest Android version, compliant with multiple screens, multi-touch, and multi-channel audio, etc.

An example of integration of multi-screens is Android Q on Qualcomm SA8155 with the following specifications:

• Supports multiple display instances
• Central unit: Main screen mixed Linux and Android
• Front & Rear seat: Android screen or Linux network display
• Android Audio/Video projection via AP-IO
• Inputs from user to Linux and Android (touch, jog shuttle, mic, Linux keyboard…)
• Multi touch support for different screens
• Multi zone audio support – audio sub-mixing
• Android Audio/Video projection via AP-IO
• Inputs from user to Linux and Android (touch, jog shuttle, mic, Linux keyboard…)
• Multimedia, voice, audio/video calls, etc.
• Notifications management from Linux to Android

Since we don’t want to have duplicates of sensors or interfaces on the external Android module, we want the external module to offer only Android functionality while everything else should be controlled by the Head Unit.

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 external Android module (which doesn’t have own screen) visible – this is accomplished via projection, capturing graphical, video and audio layers and streaming those data to the head unit. The head unit displays what is needed and when it is needed.
2. Manage the interfaces in the vehicle – access to all the interfaces in the car (touch screen, buttons, climate control, GPS, camera, and other automotive sensors) from the head unit is granted to the Android module.

AP-IO enables bi-directional communications between the two systems by linking them into a single user experience system.

Architecture

We focus on the SW side of the solution, while the HW side is done by Tier1s.

AP-IO framework mainly runs on an Android module; however, some parts need to be on the Head Unit as well. It is important to emphasize that this piece on the legacy Head Unit is not big and complex and we ensure that the re-touch is minimal. The external Android module is developed from scratch.

The distributed architecture of the AP-IO solution makes it independent on any central software component which allows for video projection to run independently. On the contrary, centralized architectures bring unnecessary dependencies and limitations, consequently increasing the complexity of managing and maintaining those systems. With the decentralized approach it is possible to add different Android features without having to re-initialize the overall system each time.

We can customize the existing interfaces and acquire additional interfaces. We can access the camera by using any standard Android application (Skype, Viber etc.) to measure performance and test capabilities.

Key components:

Additionally, this communication framework can be used independently from audio/video projection. Some OEMs, although they prefer having Android as a native system for their infotainment, want remote interfaces for the different devices that are usually not in the head unit on the same HW as the infotainment module (e.g. camera).

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, Disney+ 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’s 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, WeChat or Viber have become an almost mandatory tool for fast & 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.

Who will use this product? Target audience

Tier 1 – Tier1s are responsible for the HW side of the product, delivering USB 3.0 external HW system.
App providers – Relevant application set is important to ensure scalability and compatibility. No additional effort is required by app publishers. This partnership allows for verification that all the apps can run in a system.
OEMs – Licensing of our add-on Android enabler solution adds Android capabilities to existing OEM IVI. With our solution, OEMs have the possibility to continually upgrade HW, to address the life cycle of the Android based applications.

Why is it important (the big picture)?

A solution enabling the usage of the Android based apps should have more than a single alternative in order 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.

Competitors

Google is already implementing a very similar architecture. The difference with the Google solution relies on Android Automotive GAS and intends only to solve the Android lifecycle problem.

Outline the features of the product

• Audio and video projection
• Voice and touch events capturing
• Custom events and commands
• GPS
• Camera
• Automotive sensors

Demos