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.
Car Settings Structure. Car Settings provides a car-ified visual user interface, basic driver distraction optimizations, and additional customization entry points for OEMs.
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.
- System UI. The System UI provides the elements needed to customize UI elements including the navigation bar, status var, and volume controls.
These terms are used in HMI and related articles:
|Core apps||The key set of applications 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 application 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.|
What's Not Addressed?
The following material is not addressed in this article:
- All Google Automotive Services apps. Maps, Assistant, Play Store, Setup Wizard, and Keyboard.
- Release process.
- Integration validation and certification.
The AOSP implementation of the System UI and other core system applications 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.
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 applications to listen for changes
related to driving state to modify the user experience appropriately. OEMs can overlay the
configuration file at
to affect the behavior of the system.
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:
- Car overlay.
OEMs are expected to have a parallel overlay structure to the
in their vendor directory that further extends the
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
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.
Android Automotive includes a set of core system applications critical to overall system functionality. Of these, Communication Center, Media, Notifications, and Settings are considered hero applications.
- Communication Center
- IME (keyboard)
- Launcher (home screen)
- Local Media Player
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 applications 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 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 PIe, only available to bundled system apps running as
CATEGORY_CAR_EMERGENCY. Ranked at the top of the notification list. Bypasses Do-Not-Disturb (DND) controls.
CATEGORY_CAR_WARNING. Ranked below emergency, but above all the rest. Also 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.
The standard DeviceDefault theming and resource overlays apply. A very limited number of behavioral customization knobs are available at:
Notification configuration values of appearance and functionality can be refered here.
The Settings application (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 application 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).
The Settings application 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:
Hierarchy customization. To enable the:
Launch into an arbitrary root fragment, overlay the value of
config_settings_hierarchy_root_fragmentin the file entitled
Customization of items such as order, grouping, text, and icons, overlay
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 application (
apk) hosts a Settings screen that must be linked from the main Settings app, the separate application can be dynamically injected. For more information, see Dynamic Preferences.
Media is a hero app that provides the front-end user experience on behalf of media applications that implement the MediaSession and MediaBrowser APIs. Media applications 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.
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.
Other Media apps
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.