Android Automotive and its Customisation

Android Automotive is a specially designed Android OS and platform used for powering  In-Vehicle- Infotainment applications in vehicles.  Just like Android OS for mobile devices, Android Automotive also comes with pre-installed IVI system Android applications as well as optional other Android Applications.

Android Automotive is open source and allows customisation. The architecture of Android Automotive is as follows:-

Android Automotive differs from the usual Android in the sense it has three additional components depicted at right hands side of diagram Vehicle Network Service, Car Service and Car API.

Vehicle Network Service runs over a Vehicle HAL. A Vehicle HAL may be implemented as a dedicated MCU that can interact with and interpret the underlying Vehicle Communication Technology like CAN signals. MCU  converts the various functional (like HVAC) instructions to CAN signals which is then interpreted by the functional ECU ( HVAC ECU) and vice versa. The Vehicle Network shares this information with the CPU running Android Automotive.  The Vehicle HAL defines Vehicle Properties that can be either set or queried and these belong to one of the several functions that an OEM can implement.

The CarService just like other Android Services uses Binder to get the Vehicle specific data From Vehicle Network Service and makes it available for apps running on IVI through CAR Api.

Customising the Android Automotive for an OEM

You can customize the look and feel of the system and 3^rd party apps which are part of Android Automotive. The Car UI Library that comes with Android Automotive can serve as a customization API  by defining  which resources can be customized and which UI components (like CarRecyclerView) can use these resources. These customizations can be applied in following 3 ways

1. Build time Overlays – As the name suggests this customization is applied at the build time. When you are packaging systems with your Android Automotive OS image during build time, you can actually provide customization in overlay folder by defining these folders  in makefiles. These fodlers can contain drawables, styles ,shared resources.
2. Dynamic Run time Overlays ( dynamic RRO) : Dynamic RROs are apks that contain customized resources and a manifest file which defines which target APK it will affect.Dynamic RROs are compiled separately like other non system apps. When the system searches for a resource for an application it also checks for RRO if it has the resource with the same name. But they come with a flexibility that thye can be turned on or off. These resources can refer to either values defined within same RRO or an Android framework resource or a Build time overlay resource.
3. Static Runtime Overlays:- These are like dynamic RROs in the structure ie they are apks with customized resources and manifest file but they are always on, meaning they cannot be switched off without performing a full system image upgrade.

The Car UI library provides a mechanism to directly replace the resources (statically linked into each app) with the customized OEM Resources using a set of Static RROs. OEM must provide a folder containing their customized overlays and a list of targeted applications. During build the Car UI library infrastructure would use this information to generate one static RRO for each targeted application.

The proposed customization overlay structure is as follows:

• <path-to-OEM-overlays>/
  • overlay/framework/base/core/res/. Build-time overlay resources
  • rro/
    • Android.mk. Makefile used to generate the RROs for each target package based on the resources contained in this folder.
    • AndroidManifest.xml. A manifest file template used by the above makefile.
    • res/. Runtime overlays to apply to all target applications.