Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
Stay organized with collections
Save and categorize content based on your preferences.
The Car User Interface (UI) toolkit provides a UI development framework you can use to
ensure apps present in cars (Google apps and system and vendor apps) can attain:
Infotainment UI/UX self-consistency. Self-consistency is the ability for a
user to predict how to interact with an infotainment system based on previous experiences
interacting with the same system.
Customization. OEMs can modify the look-and-feel of the system to best
integrate functionality with vehicle interior and hardware.
To learn more about Car UI Library integration, see these pages:
The Car UI library is a statically linked library, which provides a set of components and
resources you can use to implement:
System and OEM apps (Gerrit)
Android Automotive (AAOS) apps
This library serves as a:
Customization API by:
Defining which resources can be customized including, colors, dimensions, and drawables.
Treating the resources as an API with backwards-compatible guarantees.
Compatibility layer between the short-term provided in Android 9 and Android 10 and the
longer term solution currently being developed.
Resource overlays
Android currently provides several ways to apply customizations without additional work needed to
the affected subsystems and apps:
Build-time overlays. This customization is applied at Android system image
build time. During the build, all apps in the system receive resources from their
res folder and from overlay folders defined in the target
makefiles.
Dynamic runtime overlays (dynamic RRO). These special APKs contain
only resources and a manifest file to indicate which target APK they will
affect. Dynamic RROs are compiled and deployed independently of the system image and can be
toggled on and off. When the system performs a resource lookup for a specific app, the
system also checks for any RRO targeting it and if the RRO contains a resource with the
same name.
Static runtime overlays (static RRO). Similar to dynamic RROs in structure,
these are always on, meaning they can't be uninstalled or updated without performing a
full system image upgrade. Static RROs serve as an intermediate of build-time and dynamic
runtime overlays.
In addition to UI components, the Car UI library provides a mechanism to directly overlay
resources (statically linked into each app) with the OEM resources, using a set of static
RROs. OEMs must provide a folder containing their resource overlays and a list of targeted
apps. During a build, the Car UI library infrastructure would use this information to
generate one static RRO for each targeted app.
Figure 1. Car UI library components
In the image above:
Green. Customization provided by the OEM, a mix of build-time and run-time
overlay resources.
Yellow. Support provided by Car UI library, including overlayable
resources, components (Java code) and build support to generate the necessary RROs.
Blue.Customizable targets including the framework, system
apps, vendor apps and GAS apps that use the Car UI library to
customize UI elements.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-03-13 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-03-13 UTC."],[],[],null,["# Car UI library integration guide\n\nThe Car User Interface (UI) toolkit provides a UI development framework you can use to\nensure apps present in cars (Google apps *and* system and vendor apps) can attain:\n\n- **Infotainment UI/UX self-consistency.** Self-consistency is the ability for a\n user to predict how to interact with an infotainment system based on previous experiences\n interacting with the same system.\n\n- **Customization.**OEMs can modify the look-and-feel of the system to best\n integrate functionality with vehicle interior and hardware.\n\nTo learn more about Car UI Library integration, see these pages:\n\n- [Integrate the Car UI library into apps](/docs/automotive/hmi/car_ui/integrate)\n- [Customize apps](/docs/automotive/hmi/car_ui/customize)\n- [Add custom fonts](/docs/automotive/hmi/car_ui/fonts)\n- [Customize Car UI preferences](/docs/automotive/hmi/car_ui/caruipreference)\n- [CarUiListItem](/docs/automotive/hmi/car_ui/caruilistitem)\n- [Customize CarUiRecyclerView](/docs/automotive/hmi/car_ui/caruirecyclerview)\n- [Troubleshoot runtime resource overlays](/docs/core/runtime/rro-troubleshoot)\n- [Release notes](/docs/automotive/hmi/car_ui/release_notes)\n- [Appendix A, work with RROs](/docs/automotive/hmi/car_ui/appendix)\n- [Appendix B, customization guidelines](/docs/automotive/hmi/car_ui/appendix_b)\n\nAbout the Car UI library\n------------------------\n\nThe Car UI library is a statically linked library, which provides a set of components and\nresources you can use to implement:\n\n- System and OEM apps (Gerrit)\n- Android Automotive (AAOS) apps\n\nThis library serves as a:\n\n- Customization API by:\n\n - Defining which resources can be customized including, colors, dimensions, and drawables.\n - Treating the resources as an API with backwards-compatible guarantees.\n- Compatibility layer between the short-term provided in Android 9 and Android 10 and the longer term solution currently being developed.\n\nResource overlays\n-----------------\n\nAndroid currently provides several ways to apply customizations without additional work needed to\nthe affected subsystems and apps:\n\n- **Build-time overlays.** This customization is applied at Android system image\n build time. During the build, all apps in the system receive resources from their\n `res` folder and from `overlay` folders defined in the target\n makefiles.\n\n- **Dynamic runtime overlays (dynamic RRO).** These special APKs contain\n *only* resources and a manifest file to indicate which *target APK* they will\n affect. Dynamic RROs are compiled and deployed independently of the system image and can be\n toggled on and off. When the system performs a resource lookup for a specific app, the\n system also checks for *any* RRO targeting it and if the RRO contains a resource with the\n same name.\n\n- **Static runtime overlays (static RRO).** Similar to dynamic RROs in structure,\n these are always *on*, meaning they can't be uninstalled or updated without performing a\n full system image upgrade. Static RROs serve as an intermediate of build-time and dynamic\n runtime overlays.\n\nIn addition to UI components, the Car UI library provides a mechanism to directly overlay\nresources (statically linked into each app) with the OEM resources, using a *set of static\nRROs*. OEMs must provide a folder containing their resource overlays and a list of targeted\napps. During a build, the Car UI library infrastructure would use this information to\ngenerate one static RRO for each targeted app.\n| **Note:** This mechanism will become obsolete in Android 11 (and higher) when RROs can target Android libraries.\n\n**Figure 1**. Car UI library components\n\nIn the image above:\n\n- **Green**. Customization provided by the OEM, a mix of build-time and run-time\n overlay resources.\n\n- **Yellow.** Support provided by Car UI library, including *overlayable*resources, components (Java code) and build support to generate the necessary RROs.\n\n- **Blue.** *Customizable* targets including the framework, system\n apps, vendor apps and GAS apps that use the Car UI library to\n *customize* UI elements."]]
