Introduction to Android Automotive OS Theming

Android Automotive OS (AAOS) is Google’s full-stack, open-source platform powering the infotainment systems in modern vehicles. Unlike traditional Android, AAOS is designed to be deeply integrated with vehicle hardware and services, offering a highly customizable and branded user experience. One of the most common requirements for OEMs (Original Equipment Manufacturers) is to themefy the System UI to align with their brand identity. This involves modifying everything from colors and fonts to icons and layout structures of core components like the status bar, navigation bar, and notification shade. This expert-level guide will walk you through the process of deeply customizing the AAOS System UI, focusing on resource overlays within the Android Open Source Project (AOSP).

The Challenge of AAOS Theming

Direct modification of System UI source code is often cumbersome and prone to merge conflicts during AOSP upgrades. A more robust and maintainable approach involves using Android’s resource overlay system. This allows you to override specific resources (colors, drawables, layouts, strings, styles) without directly touching the upstream AOSP source. For AAOS, where System UI is a critical component, understanding this mechanism is paramount.

Prerequisites for System UI Customization

Before diving into modifications, ensure you have the following:

• AOSP Source Code: A complete synchronized copy of the AOSP source tree for an AAOS-supported version (e.g., Android 12 or later).
• Build Environment: A Linux-based build environment capable of compiling AOSP. Refer to the official AOSP documentation for setup.
• AAOS Device/Emulator: An Android Automotive OS device (e.g., AOSP-on-HiKey, reference board) or a compatible emulator setup to test your changes.
• Basic AOSP Knowledge: Familiarity with navigating the AOSP tree, `repo` commands, and the build system (`lunch`, `make`).

Understanding Android System UI Architecture

The core Android System UI components are primarily located within the `frameworks/base/packages/SystemUI` directory in the AOSP source tree. This includes the implementation for the status bar, navigation bar, quick settings, notifications, and keyguard. Most visual elements are defined through XML resources:

• `res/values/colors.xml`: Defines global colors.
• `res/values/styles.xml`: Defines UI component styles.
• `res/values/dimens.xml`: Defines dimension values (padding, margins, text sizes).
• `res/drawable*/`: Contains various drawable assets (icons, backgrounds).
• `res/layout*/`: Defines the structure of UI components.

Our goal is to selectively override these resources using a product-specific overlay.

Step-by-Step System UI Customization via Overlays

Step 1: Setting Up Your AOSP Build Environment

First, ensure your AOSP environment is ready. Synchronize your repository and set up the build environment:

repo init -u https://android.googlesource.com/platform/manifest -b android-13.0.0_rXX
repo sync -j8
source build/envsetup.sh

Next, choose an AAOS target, for example, the `car_x86_64-userdebug` for an emulator:

lunch car_x86_64-userdebug

Step 2: Identifying Target System UI Resources

Navigate to the System UI package and identify the resources you wish to change. For instance, to change the default accent color, you might look into `frameworks/base/packages/SystemUI/res/values/colors.xml`. You’ll find entries like:

<color name="system_accent1_0">#ff4d318e</color>

Or to modify a specific layout for the status bar, you’d examine `frameworks/base/packages/SystemUI/res/layout/status_bar.xml`.

Step 3: Creating a Product Overlay

This is the crucial step for theming. You will create a new directory structure within your product’s overlay path. For an AAOS build, this typically resides under `device/<vendor>/<product>/overlay`. Let’s assume your product is `mycar` and your vendor is `mycompany`.

Create the following directory structure:

device/mycompany/mycar/overlay/frameworks/base/packages/SystemUI/res/values/

Now, create a `colors.xml` file inside this new `values` directory. Only include the colors you want to override. For example, to change the accent color and a background color:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!-- Custom accent color for our brand -->
    <color name="system_accent1_0">#ff007bff</color> <!-- Blue -->
    <color name="status_bar_background">#ff2a2a2a</color> <!-- Dark Gray -->
</resources>

The build system will automatically pick up these overlay files and use them instead of the original AOSP resources when compiling `SystemUI` for your product.

Overriding Layouts and Drawables

The same principle applies to layouts and drawables. If you want to modify `status_bar.xml`, copy it to your overlay path and make changes:

device/mycompany/mycar/overlay/frameworks/base/packages/SystemUI/res/layout/status_bar.xml

Then, edit the `status_bar.xml` in your overlay with your desired layout adjustments. For drawables, if you want to replace `ic_launcher.xml`, place your custom version at:

device/mycompany/mycar/overlay/frameworks/base/packages/SystemUI/res/drawable/ic_launcher.xml

Ensure the resource names in your overlay exactly match those in the original AOSP `SystemUI` package to ensure proper overriding.

Step 4: Building and Flashing the Customized Image

After making your overlay changes, you need to rebuild the relevant modules and flash the updated image to your device or emulator.

1. Clean and Rebuild SystemUI: While you can rebuild the entire AOSP, a faster approach is to rebuild only `SystemUI` and its dependencies. However, for resource overlays to be properly picked up by the build system, it’s often safer to rebuild the entire `frameworks/base` or even a full build if you’re unsure.

   make -j$(nproc) SystemUI

   Or, for a complete image:

   make -j$(nproc)

2. Flash the Image: Once the build completes, power off your AAOS device and boot it into fastboot mode. For an emulator, you would typically rebuild and then launch the emulator.

   # On your host machine
   adb reboot bootloader
   fastboot flashall -w

   The `-w` flag wipes user data, which is often necessary to avoid conflicts from previous installations. If you’re updating an existing system, you might flash specific partitions like `system`, `vendor`, `product` if you know which ones contain your changes.

3. Verify Changes: After rebooting your device, observe the System UI. You should see your custom colors, layouts, or drawables reflected in the status bar, navigation bar, quick settings, and other relevant areas.

Best Practices and Considerations

• Version Control: Always keep your overlay changes under version control (e.g., Git) to track modifications and facilitate future AOSP upgrades.
• Modularity: Structure your overlay logically. If you have multiple products or variations, consider separate overlay directories for better management.
• Testing: Thoroughly test your themed System UI across different vehicle states, screen sizes, and orientations to ensure stability and visual consistency.
• Performance: While resource overlays generally don’t impact performance significantly, excessively complex layout overrides could have minor implications. Always profile if you notice slowdowns.
• OTA Updates: Plan how your customizations will be integrated into over-the-air (OTA) updates. Overlays make this process much smoother than direct source modifications.
• Runtime Resource Overlays (RROs): For dynamic theming or vendor-independent customizations, consider investigating Runtime Resource Overlays (RROs). These allow changing resources at runtime without a full system rebuild, offering greater flexibility post-installation, though they have their own set of complexities. For initial deep theming, static overlays are simpler.

Conclusion

Theming Android Automotive OS System UI is a critical aspect of creating a branded in-car experience. By leveraging AOSP’s resource overlay system, OEMs and developers can achieve deep customization without invasive changes to the core platform source code. This approach ensures maintainability, simplifies upgrades, and provides a robust foundation for building unique automotive infotainment systems. With the steps outlined in this guide, you are now equipped to take control of your AAOS device’s visual identity, transforming it to perfectly match your brand’s aesthetic.