Strategic Now: Four Customer-Driven Approaches to Harness Android

AndroidTV, AOSP, mARTini Android container, AP-IO

Strategic Now: Four Customer-Driven Approaches to Harness Android

AndroidTV, AOSP, mARTini Android container, AP-IO

Strategic Now: Four Customer-Driven Approaches to Harness Android

AndroidTV, AOSP, mARTini Android container, AP-IO

Strategic Now: Four Customer-Driven Approaches to Harness Android

AndroidTV, AOSP, mARTini Android container, AP-IO

When a customer approaches us seeking a solution for Android device development, the decision-making process often involves choosing between two prominent paths: embracing Android TV and Google Mobile Services (GMS) or opting for an Android Open Source Project (AOSP) solution. Each avenue comes with its own set of advantages and considerations.

Android TV and Google Mobile Services

This route is a comprehensive approach that integrates Google’s suite of mobile services, including Play Store, Chrome, Search, YouTube, Maps, and more. By adopting GMS, clients gain access to a vast array of productive applications and APIs specifically crafted by Google for Android device manufacturers. This approach provides uniform functionality across various Android devices, ensuring stability, security, and adherence to Google’s guidelines. Additionally, it facilitates system updates and patches, guaranteeing that applications consistently operate at their best, and supports over-the-air updates, enhancing the user experience.

Google’s effort to enforce a strong TV and entertainment-oriented architecture resulting in constant (yearly) evolution of new features, security enhancement, and exciting partners while enabling a seamless integration for all Android TV devices, produces heavy technical challenges as can be seen from our Bouygues STB project. To be able to provide consistent and manageable ecosystem that brings the beforementioned benefits, Google is requesting from the operators/OEMs to provide at least three version upgrades to the end user during the lifecycle of the products. Finally, the telecom operator also maintains their own feature roadmap with a goal to improve customer offering, features, and quality. All these elements force the telecom operators to significantly increase the amount and timing of major software updates and new devices deployments. Additional complexity arises from the fact that the new devices are usually introduced either to accommodate new features or to provide a second source and de-risk the supply chain. Not only does this level of complexity bring challenges in management of the product, but also in keeping of its software architecture well defined and regularly updated so that the long-term benefits of being a part of the Android ecosystem do not go to waste. This is where the value of a strong partner like RT-RK lies; being able to prevent and solve these issues by employing its skilled engineering force.

AOSP

Big tech companies like Amazon, ROKU, and Jio work towards creating ecosystems around their brands. The purpose of the ecosystem is to frame consumer choice and habitual purchase behavior by dominating the entire path to purchase, from awareness to decision. User’s choice of content providers, products, financial and telecom services, etc. is shaped and bound by their compatibility with these ecosystems.

The ecosystem strategy asks for huge markets. One of the major ecosystem players in India is Jio, with whom we cooperate in multiple domains, most importantly on the development of JioOS, an AOSP based platform at the heart of the Jio ecosystem.

With non-GMS devices, there is the ultimate flexibility to provision, deploy, and design purpose-built devices to fit operator/OEM’s use cases. There are tradeoffs, including the cut off from Google apps and services that would normally be available to developers. However, AOSP devices give the flexibility to make updates on operator/OEM’s own schedule and keep their firmware where they want it.

mARTini Android container

However, some customers find the transition to a full Android environment laden with complexities and risks, particularly in the automotive sector. For these clients, we present alternative approaches which allow them to harness the power of Android without undergoing a complete migration.

One such option is the mARTini approach, where Android applications operate within a container. This less integrative concept enables clients to retain their existing systems while still benefiting from the functionality of Android apps. It provides a middle ground, allowing for a gradual and less disruptive adoption of Android technology.

mARTini approach integrates Android in legacy host OS and enables Android features within an existing head-unit OS (usually Linux-based). Therefore, the overall head-unit software is kept as it is, with the containerized Android adding functionalities to the host system. While the similar widely adopted approach used for developing Android and Linux on the same SoC called hypervisor manages major functional safety automotive requirements for the two integrated operating systems, it falls short at memory distribution between multiple guest OSs. On the other hand, mARTini containerized Android approach dynamically allocates system resources (CPU, RAM, GPU) thus performing more demanding applications at reduced hardware cost.

The container approach must resolve a tradeoff between the complexity of integration and performance. mARTini approach offers both full graphics acceleration (integration with platform GPU and codec API to achieve maximal performance) and simple graphics solution (full software implementation of graphics renderer and codes for minimal hardware dependency and fast deployment), depending on the customer’s needs. 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 confirming Android compatible device, with plans to widen CTS and perform detailed verification thereof.

AP-IO (Android Projection – Infotainment I/O)

Google Play store with dedicated Android applications is filling very fast. Android systems in modern vehicles need to be continuously updated to the latest requirements of such applications. However, this has shown to be 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 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 an additional 10-15 years of life. Having Android on the head unit, at least with the currently high hardware cost, is not always a sustainable solution. This is where external hardware module comes in handy as it can be replaced with more advanced hardware easily during the vehicle life cycle and therefore keep the hardware and software fresh.

Unlike mARTini, AP-IO approach, involving the use of a coprocessor to establish a connection between the infotainment system and external hardware executing Android, offers a full Android experience. This connection can be established through a USB 3.0 single interface or a combination of HDMI and WiFi. AP-IO is a communication framework between the head unit OS and Android that enables Android features with the external hardware 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 software is kept as it is, with the external hardware module bringing Android functionalities to the host system.

Takeaway

The need for the immediate harnessing of Android is evident in both the consumer and automotive industries. While the fundamental approaches originate in the consumer world, the automotive industry, aiming for incremental integration, explores options to preserve legacy platforms and harness Android through either the container approach or external hardware. The versatile needs of the industries take these two novel approaches, developed with mobility in mind, namely container and AP-IO, even further. Off-highway vehicles, devices for control, and other non-automotive Linux legacy systems show interest in exploiting Android through integration in containers to benefit from Android applications. AP-IO, developed fully with mobility in mind, will also be utilized in completely stationary consumer systems to render graphics on external hardware while establishing the connection via USB 3.0 or HDMI+WiFi.

You may also like