HMI overview

Android Automotive is an in-car infotainment platform solution provided with the Android Open Source Project (AOSP). The articles in this topic introduce the key concepts and components provided by the Android Automotive System UI and core apps needed to build an effective Human Machine Interface (HMI) system for OEMs, third-party developers, and end users.

  • AOSP Host Integration Guide. The App Host allows 3P car apps to render OEM-styled user interface (UI) components on its behalf.
  • Car Settings Structure. Car Settings provides a car-centric visual user interface, basic driver distraction optimizations, and additional customization entry points for OEMs.
  • Car UI Library Integration Guide. The Car UI Library provides a UI development framework to enable all apps present in the car to achieve consistency and customization.
  • Customize Status Bar System Icons. The Status bar is a component of the Android System UI used to persistently display important information to users. Learn how to customize the Status bar system icons.
  • Heads-Up Notifications. Learn how to customize Heads-Up Notifications.
  • Dialer. Use this Android system app to implement a distraction-optimized (DO) experience for Bluetooth calling, contact browsing, and call management.
  • Media. With just a few settings and a service, developers can extend existing media apps. While apps must adhere to the Automotive Media template, developers can customize template colors, fonts, icons, and more to create a branded experience.
  • Notifications. Learn how to change the appearance and configurations of notifications.

Terminology

These terms are used in HMI and related articles:

Term Definition
Core apps The key set of apps critical to system functionality, including Settings, Radio, HVAC, Media, Dialer, and Keyboard.
Compatibility Definition Document (CDD) Enumerates the requirements that must be met for devices to be compatible with the latest version of Android.
Compatibility Test Suite (CTS) Free, commercial-grade testing suite, available for download at Compatibility Test Suite Downloads.
Customization The exercise of modifying an AOSP implementation to meet the requirements of an OEM. Typically, this involves the use of resource overlays to apply cosmetic changes while also ensuring compliance with the CDD, CTS, and all relevant User Experience guidelines.
Hero apps A set of key apps critical to all aspects of Android, including functionality, upgradability, third-party developer ecosystem, and end users. Hero apps include Notifications, Settings, Media, and the Communication Center/Dialer. Corresponding AOSP implementations should be of production quality.
Resource overlays To affect the rendering of the user interface, use this mechanism to replace colors, change dimensions, enable drawing, and apply layout resources either at compile time (most common) or at runtime (Runtime Resource Overlays (RRO)).
System UI The user interface outside an app that belongs to the system, such as the navigation bar, status bar, lock screen, and volume dialog.
Theme A collection of colors and styles used to determine the look-and-feel of the components and apps that inherit the theme.
User Experience (UX) The field of User Interface (UI) design and its usability.

Customization

The AOSP implementation of the System UI and other core system apps serves as a strong foundation for starting the HMI development process. The exercise of modifying the AOSP implementation (primarily through the use of resource overlays) to meet an OEM's branding, business, and legal requirements is referred to as customization.

While the overall system is designed and built to be flexible, different components are expected to be customized to different degrees:

  • System UI. OEM can customize or replace the AOSP implementation within the bounds afforded by the CDD and CTS and any other applicable UX guidelines.

  • Non-hero system apps (also known as reference). OEMs can customize or replace the AOSP implementation.

  • Hero apps. Each app comes with a set of detailed customization guidelines. OEMs are strongly encouraged to use the AOSP implementation and then customize it within the bounds afforded by those guidelines.

Density configuration

To ensure that UI elements render properly given the physical display configuration, the density property must be set to the bucket (Display Metrics) that matches the physical density most closely, such as this entry in the build file:

PRODUCT_PROPERTY_OVERRIDES := \
        ro.sf.lcd_density=160

UX restrictions engine

CarUxRestrictionsManager provides a hook for apps to listen for changes related to driving state to modify the user experience appropriately. OEMs can overlay the configuration file at packages/services/Car/service/res/xml/car_ux_restrictions_map.xml to affect the behavior of the system.

System theme

The theme that prescribes the system-wide default set of items such as colors and text styles is DeviceDefault. OEMs are encouraged to start the overall customization process by modifying the DeviceDefault theme. By default, the system UI, and all the system apps in AOSP, inherit from this theme. OEM-developed system apps are also encouraged to inherit DeviceDefault. Third-party developed apps are not expected to inherit DeviceDefault but to instead use Theme.Car provided in the androidx.car library. Files are located as follows:

  • Core. /frameworks/base/core/res/res/values/themes_device_defaults.xml
  • Colors. /frameworks/base/core/res/res/values/colors_car.xml
  • Styles. /frameworks/base/core/res/res/values/styles_car.xml
  • Car overlay.
    /packages/services/Car/car_product/overlay/.../values/themes_device_defaults.xml

OEMs are expected to have a parallel overlay structure to the car_product directory in their vendor directory that further extends the car_product overlay.

Theme Playground app

This app streamlines the process of customizing the DeviceDefault theme by visualizing all theme attributes in one place. Also, by comparing how certain styles render in this app as comparied to other system apps, developers can quickly debug theme issues. This app is available at:

  /packages/services/Car/tests/ThemePlayground

System UI

System UI includes all the UI under /frameworks/base, primarily in /frameworks/base/packages/CarSystemUI. This includes the Navigation bar, Status bar, lock screen, volume dialog, toasts, user picker, and permission dialogs. OEMs can customize the system UI components extensively via resource overlays and theming, provided each is within the requirements of the CDD, CTS, and other applicable UX guidelines.

System apps

Android Automotive includes a set of core system apps critical to overall system functionality. Of these, Communication Center, Media, Notifications, and Settings are considered hero apps.

  • Communication Center
  • HVAC
  • IME (keyboard)
  • Launcher (home screen)
  • Local Media Player
  • Media
  • Messenger
  • Notifications
  • Radio
  • Settings

Home screen

The Home screen, known as the Car Launcher, is the landing page for the HMI experience. The AOSP implementation serves as a reference only and OEMs are expected to replace the implementation with their own, which often combines navigation, media playback, communication, and other system states, as needed. Often, the Car Launcher app is displays the apps available on the system. To learn how to handle events such as recents, package changes, and headless (no launcher activity) apps, see the reference implementation.

Notifications

Notifications are an integral component of the Android OS and the same constructs (including heads-up notification, notification list/center, Notification APIs, ranking, and inline actions) have been included in Android Automotive. For details, see the handheld Notifications Overview. To optimize automotive use cases, the following modifications have been made (as compared to the handheld notification stack):

  • Reduction in overall notification content visible to users. Removal of ongoing media playback, ongoing navigation, and "unimportant" (importance of LOW and below) foreground service notifications of system apps from the notification list/center, with the understanding that these notifications are either made redundant (eg. cluster showing media state) or are not useful.

  • Removal of complex contextual controls (such as long press and swipe-length-based controls).

  • Respecting the UX Restrictions engine configuration.

    • Messaging notification content preview may be hidden based on drive-state.
    • All strings capped at max length.

  • Addition of new notification categories specifically for cars in Android 9, only available to bundled system apps running as android.uid.system.

  • CATEGORY_CAR_EMERGENCY. Ranked at the top of the notification list. Bypasses Do-Not-Disturb (DND) controls.

  • CATEGORY_CAR_WARNING. Ranked below emergency and above others (bypasses DND).

  • CATEGORY_CAR_INFORMATION. Ranked with the rest of the notifications based on "importance" and recency.

The end-to-end implementation of the notification stack, from Notification APIs to the UI, is considered a hero app. To guarantee consistent API interoperability across all HUs and to maximize upgradeability, OEMs are strongly encouraged to take the AOSP implementation and then customize it lightly.

Customization

The standard DeviceDefault theming and resource overlays apply. A very limited number of behavioral customization knobs are available at:

packages/apps/Car/Notification/res/values/config.xml

Settings

The Settings app (Car Settings) is one of the hero apps that exposes knobs, which the user can use to configure aspects of the Android OS and the rest of the car. The Settings app exposes more than 200 features in the OS, which are tightly coupled with each major Android release. To enable upgradeability and to avoid fragmentation, OEMs are strongly encouraged to take the AOSP implementation and then customize it (instead of forking the implementation).

Customization

The Settings app takes customization into account and exposes several avenues for customization.

  • Theming. Enables the visual customization of how each Preference object type is to be rendered, including:

    • Preference.DeviceDefault.CheckBoxPreference

    • Preference.DeviceDefault.DialogPreference.EditTextPreference

  • Hierarchy customization. To enable the:

    • Launch into an arbitrary root fragment, overlay the value of config_settings_hierarchy_root_fragment in the file entitled Settings/res/values/config.xml

    • Customization of items such as order, grouping, text, and icons, overlay Settings/res/xml/*.xml

  • Static injection. While setting up an overlay project, OEMs can add proprietary screens by defining and then adding the additional Fragment and Controller classes to the hierarchy.

  • Dynamic injection. If a separate app (apk) hosts a Settings screen that must be linked from the main Settings app, the separate app can be dynamically injected. For more information, see Dynamic preferences.

Media

Media is a hero app that provides the front-end user experience on behalf of media apps that implement the MediaSession and MediaBrowser APIs. Media apps can be third-party apps (such as Spotify and Pandora) as well as other media sources, such as Bluetooth (BT) streaming and local media.

Hundreds of media apps are available in Android Auto (Projection), all of which implement these media APIs as described in Providing Audio Playback for Auto. Media APIs evolve with each major Android release and with releases of the Androidx library. To guarantee API interoperability across all media apps and future versions of Android, OEMs are strongly encouraged to take the AOSP implementation and then customize it.

Customization

Standard theming through the DeviceDefault theme also applies to Media. In addition, further customization of the look-and-feel is possible with resource overlays, provided the customization is within the bounds of the UX guidelines.

USB media and media sources

To the extent possible, it is highly recommended these media sources be plugged in to Media through an implementation of the MediaSession and MediaBrowser APIs (this is true of any third-party media app). See the LocalMediaPlayer app in the AOSP. This app surfaces local media files and is displayed as a source in Media.