Introduction to AAOS Multi-Display Systems

Modern automotive experiences are no longer confined to a single central display. Android Automotive OS (AAOS) provides robust frameworks to manage multiple displays, enabling rich, context-aware user interfaces across various screens within a vehicle. This guide delves into the technical intricacies of configuring and managing multi-display setups in AAOS, from hardware abstraction to application-level development, ensuring a seamless and immersive automotive user experience.

Multi-display support in AAOS is crucial for scenarios like passenger entertainment, digital instrument clusters, head-up displays (HUDs), and rear-seat controls. Properly configuring these displays involves understanding hardware capabilities, system-level configurations, and application targeting.

Understanding Display Concepts in AAOS

AAOS categorizes displays into several key types and introduces the concept of display zones to manage their usage effectively.

Physical vs. Virtual Displays

• Physical Displays: These are actual hardware screens connected to the SoC, such as the infotainment display, instrument cluster, or passenger display. Each physical display has a unique display ID.
• Virtual Displays: These are software-rendered surfaces that can be streamed to external sources (e.g., a rear-seat entertainment system via HDMI-out or Wi-Fi Display) or used internally for specific purposes like screen recording.

Display Zones and User Roles

AAOS introduces the concept of display zones, which are logical groupings of displays. Each zone can be associated with specific user roles (e.g., driver, passenger) and a particular type of user experience. This allows for fine-grained control over what content is shown where, and who can interact with it.

• Primary Zone: Typically associated with the main infotainment display, accessible by the driver and potentially front passenger.
• Passenger Zone: Dedicated to displays intended for passenger use, often with independent media playback or navigation capabilities.
• Cluster Zone: Specifically for the digital instrument cluster, displaying critical driving information.

The system property android.car.property.PROPERTY_SECONDARY_DISPLAY_ID indicates the ID of a secondary display if one is configured, providing a programmatic way to identify displays within zones.

Hardware and System Configuration

Setting up multiple displays begins with the underlying hardware and kernel configurations.

Device Tree Overlay (DTO/DTBO)

The first step involves defining the physical display connections in the device tree. This specifies the display controllers, panel characteristics, and any necessary timing or interface details. For example, a simple device tree entry for an additional display might look like:

&i2c1 {  display_panel@0 {    compatible = "vendor,secondary-display-panel";    reg = <0x2c>;    status = "okay";    port {      display_in_secondary: endpoint {        remote-endpoint = <&display_controller_secondary_out>;      };    };  };};

This defines a secondary display panel connected via I2C. The specifics will vary greatly depending on your SoC and display hardware.

Display Configuration XML (`display_configuration.xml`)

After the kernel recognizes the physical displays, AAOS uses a system-level XML file, typically located at /vendor/etc/car_display_configuration.xml (or similar path depending on your vendor implementation), to define display properties and associate them with zones. This is critical for AAOS to understand the capabilities and roles of each screen.

Here’s an example structure for configuring a primary and a passenger display:

<carDisplayConfiguration>  <display id="0">    <associatedZones>      <zone id="0"> <!-- Primary Zone --> </zone>    </associatedZones>    <isDriverDisplay>true</isDriverDisplay>    <isMainDisplay>true</isMainDisplay>  </display>  <display id="1">    <associatedZones>      <zone id="1"> <!-- Passenger Zone --> </zone>    </associatedZones>    <isDriverDisplay>false</isDriverDisplay>    <isMainDisplay>false</isMainDisplay>    <canShowActivityInConfiguredTaskDisplayArea>true</canShowActivityInConfiguredTaskDisplayArea>  </display>  <zone id="0" displayName="Front Zone" />  <zone id="1" displayName="Passenger Zone" /></carDisplayConfiguration>

In this example:

• display id="0" is configured as the primary (main) driver display.
• display id="1" is designated as a passenger display, able to show activities in its own task display area.
• The isDriverDisplay and isMainDisplay flags are crucial for AAOS system services.

Application Development for Multi-Display

Once the system is configured, applications need to be aware of and target specific displays.

Querying Available Displays

Applications can query available displays using DisplayManager or CarDisplayManager (part of the Car API). CarDisplayManager provides automotive-specific context, such as display zones.

import android.car.Car;import android.car.CarDisplayManager;import android.view.Display;import java.util.List;public class MultiDisplayHelper {    public void logDisplays(Car car) {        CarDisplayManager carDisplayManager = (CarDisplayManager) car.getCarManager(Car.CAR_DISPLAY_SERVICE);        if (carDisplayManager != null) {            List<Display> displays = carDisplayManager.getAllDisplays();            for (Display display : displays) {                int displayId = display.getDisplayId();                int displayZone = carDisplayManager.getDisplayZone(displayId);                Log.d("MultiDisplay", "Display ID: " + displayId + ", Zone ID: " + displayZone);                // Get display info like width, height                Point size = new Point();                display.getRealSize(size);                Log.d("MultiDisplay", "Resolution: " + size.x + "x" + size.y);            }        }    }}

Targeting Activities to Specific Displays

Launching an activity on a specific display is achieved using ActivityOptions.

import android.app.ActivityOptions;import android.content.Context;import android.content.Intent;import android.view.Display;public class DisplayActivityLauncher {    public void launchActivityOnDisplay(Context context, Class<?> activityClass, int targetDisplayId) {        ActivityOptions options = ActivityOptions.makeBasic();        options.setLaunchDisplayId(targetDisplayId);        Intent intent = new Intent(context, activityClass);        intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_MULTIPLE_TASK);        context.startActivity(intent, options.toBundle());    }}

In your application, you would retrieve the targetDisplayId (e.g., from CarDisplayManager for the passenger zone) and then use this utility method.

Handling Input on Secondary Displays

Input events (touch, key presses) are typically routed to the foreground activity on the display where the event occurred. For secondary displays, ensure your applications are designed to handle independent input streams. The system handles the mapping of physical touch controllers to the correct display’s input coordinate system.

Best Practices and Considerations

• User Experience Consistency

  Ensure a consistent and intuitive UX across all displays. While content might differ, interaction patterns and visual language should remain cohesive.

• Performance Optimization

  Running multiple graphics-intensive applications on different displays can impact performance. Optimize rendering, reduce unnecessary animations, and manage memory efficiently. Leverage hardware overlays where possible for video playback.

• Security and Privacy

  Crucial driver information (e.g., speed, navigation directions) should generally be restricted to the instrument cluster or main driver-facing display. Sensitive data should not be easily accessible on passenger displays. AAOS’s display zone management helps enforce these policies.

• Lifecycle Management

  Activities on secondary displays have the same lifecycle as those on the primary. Ensure your application correctly handles pause, resume, and destroy events, especially when displays are turned off or go into sleep mode.

• Manifest Declarations

  For applications that explicitly support multi-display, consider declaring android:allowEmbeddedDisplay=

  Android Mobile Specs & Compare Directory

  Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!

  Compare Devices Specs →