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 articles:
- Integrating the Car UI Library into Apps
- Customizing Apps
- Adding Custom Fonts
- Customizing Car UI Preferences
- Customizing CarUiRecyclerView
- Troubleshooting Runtime Resource Overlays
- Appendix A, Working with RROs
- Appendix B, Customization Guidelines
About the Car UI Library
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.
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
resfolder and from
overlayfolders defined in the target makefiles.
Dynamic runtime overlays (dynamic RRO). These special APKs contain onlyonly 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 application, 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 applications. During a build, the Car UI library infrastructure would use this information to generate one static RRO for each targeted application.
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 applications, vendor applications and GAS applications that use the Car UI library to customize UI elements.