In the Automotive Industry, the infotainment system has become a critical factor in promoting the brand. Every automotive company uses its proprietary infotainment system but, the customer wants to have a common platform like the mobile device, where they can customize and use the third-party application. The in-vehicle infotainment systems (IVI) in cars are becoming more and more sophisticated, warranting the development of rich OS designs specifically designed for IVI.
Android Automotive is a version of the Android OS customized precisely for automotive IVI systems. It integrates infotainment with other control features in an automotive, for example, Air conditioning control, providing a single rich interface for the user. Using Android Automotive OS for your car’s IVI system allows you to leverage the versatility of the Android ecosystem while customizing it for the automotive experience.
Google introduced automotive android in March 2017, and the first car with Automotive Android is scheduled for the market for 2021.
Android Automotive is not Android Auto:
Let us distinguish Android Automotive from another Android product with a similar name (Android Auto). Android Auto is a framework for connecting your phone to your car’s in-vehicle infotainment system. Automotive Android is an OS that runs on your car’s IVI system, independently of your phone.
Automotive Android is Android. It is built from the same AOSP code base as Android for Phone. Automotive Android extends Android to add features that are not present in the phone or behave differently than on the phone. It gives a richer user interface and adds a key point to promote the value of the vehicle.
Automotive Android has already been on production for some of the Tier-1 companies. Automotive Android can run directly on SoC in the IVI system. Also, it can be used with other operating systems using hypervisor or containers.
So. Let’s look into how the system architecture of the Android Auto OS.
Figure 1 System Service Architecture
Google Automotive Services (GAS):
Those familiar with Android development know that Android provides a set of services and apps (Google Mobile Services - GMS) that can be integrated into your final product, like Settings, Mail, Calendar, etc. Google Automotive Services is the name of its counterpart for automotive devices.
Vehicle HAL:
To ensure car system integrity, Android Automotive protects incoming data at these levels:
- Applications. The system verifies if an application has permission to talk to Car subsystems.
- Well-Defined APIs. Generic APIs do not accept arbitrary data blobs (APIs must be well defined).
- Car Service. Updates allowed only via OTA (or USB), with full-disk encryption and verified boot. It cannot be sideloaded.
- Vehicle HAL. Verifies specific messages are allowed.
Camera HAL:
The camera and display framework on Android for phones typically comes up late in the boot process, making it less suitable for applications like surround view and rearview cameras in cars that are required to be available within a few seconds from starting the car. Android Automotive provides the exterior view system (EVS) stack, which is used to support this automotive-specific use case. It is the responsibility of the OEM to implement both the user space and kernel support for EVS.
Displays:
Android Automotive supports multiple screens in the vehicle, using Android 10’s presentation API to support external displays. Additionally, there is support to send information via CAN or as graphics buffer in use-cases where it is preferred that instrument cluster display is driven separately from Android.
Power and Boot Time:
Power management is critical to automotive applications, and power requirements differ vastly from mobile devices, including:
- Near-zero power consumption while the vehicle is parked. The vehicle should still have enough battery charge to start, even after many months.
- Extremely fast power-on response for the rear-view camera, audio, and splash screen (before Android itself boots).
- Quick boot into the Android home screen so that the user can interact with the device.
- Resume/restore application states (such as the radio station and navigation guidance) after the power cycle.
Android Automotive introduces a new power management system to address these issues:
- Power Management. Defines the power state machine used by Android Automotive, provides example sleep/shutdown/wake sequences and lists the Vehicle HAL properties related to power management.
- Garage Mode. Defines a low power mode in which the vehicle executes necessary maintenance tasks (such as OS and application updates) while the vehicle is parked.
- Managing Boot Time. Defines differences between the Android and Android Automotive boot processes, provides tips for optimizing boot time, and gives instructions for starting services such as the rearview camera early in the boot sequence.
Connectivity:
Android 8.0 creates a seamless Bluetooth user experience when connecting devices to the in-vehicle infotainment system (IVI). The IVI listens for events, such as unlocking a car door or starting the engine and automatically scans for in-range Bluetooth devices. It will also simultaneously connect to separate devices so users can make hands-free calls on any device.
Users and Accounts:
Android Automotive supports these types of users:
- Headless System User. The headless system user runs in the background and hosts all system services. For Automotive, the system user is not intended to be used, nor directly accessed, by a physical person.
- Regular User. Automotive devices are shared devices, and each User is intended to be used by a different physical person. Android Users can have different roles. See Roles and Restrictions below for more information. In Automotive, all regular Users are Secondary users.
- Guest User. Automotive users can include temporary users, such as friends, who borrow a vehicle. To accommodate uses like this, Android Automotive provides a Guest User with access to all components needed to use the vehicle. Only one Guest User can be defined on a device at a time.
Flash Wear Management:
Flash wear management is a real problem in automotive systems because the usage pattern of flash storage in automotive applications is different from:
- Cars have a longer lifespan than typical consumer electronics. Thus, the flash in automotive IVI systems is required to last longer.
- The environmental conditions like temperature are harsher in an IVI system than on a consumer electronic product
- The usage pattern of flash by applications is considerably more for automotive applications.
Android Automotive provides options to use SD-card for the storage of application data and to control flash usage by third-party applications.
Key Advantage of Using the Automotive android
- Google will be providing the security updates regularly
- Google does some of the testings like penetration testing to make sure the system is secure
- Android new version release can be migrated, which means we can have long term support and maintenance
- OTA deployment becomes simpler using the android.
- Simpler connectivity service to other devices.
- Customers can customize the look and feel of the IVI system.
Let PathPartner be your preferred partner in bringing Android Automotive to your vehicle:
PathPartner has rich expertise in bringing up Android on various hardware platforms. Additionally, Pathpartner specializes in the niche areas required to bring up Android Automotive:
Further reading
- IVI Systems
- Camera
- Power and Boot Time Management, Flash Memory
- Android
- Safety
- Driver Monitoring Solution
