Scalable UI overview

Use Scalable UI to build sophisticated, dynamic, and multi-panel user experiences in cars. Scalable UI:

  • Provides a flexible windowing system.

  • Minimizes engineering risks, costs, and complexities presented by the Compatibility Test Suite (CTS) for user interface implementations.

Scalable UI supports a wide range of modern In-Vehicle Infotainment (IVI) designs that need dynamic window arrangements, while scaling down to support traditional experiences with static window arrangements, too.

Android 17 introduces the following features specific to advanced windowing:

Sample experiences

Scalable UI enables an infinite variety of windowing configurations. Here are a few sample scenarios created to exercise Scalable UI:

Map background with floating apps

A map background configuration with other applications floating on top.

App background

An application background configuration with floating panels.

Pinned app under other apps

A pinned application, such as a widget container, with other applications launching on top.

Conditional floating panel

A conditional floating panel that appears only when specific conditions are met, such as when media is playing or when an alert triggers.

Pinned app close to driver

A pinned application positioned closer to the driver.

Split screen layout

A split-screen layout displaying two applications side-by-side.

Interactive split screen

An interactive split-screen layout allowing dynamic resizing.

Multianchor layout for large screens

A multianchor layout designed for large screens.

A home screen layout featuring an application carousel.

Benefits and compliance

Scalable UI benefits include:

  • Lower test risk: The framework is pre-certified and compliant with the CTS, which eliminates the primary risk of test failures late in a program cycle. Scalable UI can save months of engineering effort and accelerate compliance.

  • More design flexibility: Proven capability to recreate numerous complex existing automotive windowing models. Scalable UI supports ambitious and highly differentiated designs.

  • Less implementation complexity: Abstraction into a high-level, config-driven XML model lowers the barrier to entry for custom windowing logic.

  • Better performance: Scalable UI runs on a high-performance windowing foundation, fully integrated with standard Android. Transitions flow smoothly, allowing direct optimization.

Core building blocks

Scalable UI minimizes the need for OEM-specific code, eases updatability, and reduces launch risks by eliminating pitfalls and reducing certification issues.

The XML-driven approach addresses common challenges when managing complex windowing systems in AAOS, such as precise positioning, Z-order conflicts, and app focus.

Scalable UI provides these core building blocks.

Panel

A panel is the fundamental rectangular container on the screen. Each panel maps to a dedicated root task for independent management. A panel can host app tasks (TaskPanel) or view-based content, such as widgets (DecorPanel). To learn more, see Configure a panel.

Variant

A variant defines a specific visual state for a panel and includes properties such as bounds (position and size), visibility, layer (Z-order), and corner radius. A single panel can have variants, such as opened, closed, or minimized. To learn more, see Use a variant to design a visual state.

Transition

A transition defines how a panel moves from its current state fromVariant to a new state, toVariant. An Event triggers the transition, which defines the animation that the panel uses during the state change. A panel should move from its current state to toVariant. For synchronization, the core Window Manager animates and coordinates all transitions.

  • Event: A trigger to initiate a UI change. An OEM or the system can predefine a trigger. For example, _System_OnHomeEvent, _System_TaskOpenEvent, or a custom navigation button press.

For example, Scalable UI uses events to trigger transitions. These transitions animate a panel from one variant to another to display dynamic changes in the UI. Scalable UI communicates these changes to other system apps to adjust content as needed. By defining UI relationships in XML, you can:

  • Specify complex UI behaviors: Define intricate user interface interactions.

  • Arrange windowing systems: Control window positioning and layering.

  • Implement visual themes: Apply consistent branding and aesthetics.

  • Reduce code complexity: Minimize the need for extensive custom code development.

To learn more, see Configure a transition.

System UI buttons

In addition to triggering intents, CarSystemBarButtons can trigger a Scalable UI event when tapped using event, selectedEvent, and unselectedEvent attributes.

event describes the event to be triggered when the button is tapped. If more granular control over an event is required, use the selectedEvent and unselectedEvent attributes to specify the event to trigger when the button is selected or unselected, respectively.

When to implement System UI

This section describes optimal uses of Scalable UI.

Create persistent multipanel layouts

Create a multi-zone experience in which different areas of the screen are permanently dedicated to specific functions. For example, dedicated media controls, a climate strip, or a full-screen map.

Use TaskPanels for primary apps (such as navigation) and DecorPanels for UI elements, in the form of views, that must be placed between TaskPanels.

Implement a dynamic home scene

Implement a Home scene composed of multiple, concurrently visible, and interactive app panels. For example, map, media player, and app grid.

To transition all relevant panels to their opened or default home variants, configure _System_HomeEvent.

Apply contextual overlays

Place non-app UI elements, such as contextual widgets, custom branding, and drag bars that can be animated in coordination with app tasks.

Use DecorPanels for all purely decorative or widget-hosting elements. If a widget hosts a fully functioning, launchable app, a Panel > TaskPanel is optimal. Use DecorPanels for view-based UI elements when layering must be synchronized with the TaskPanel layering.

Design complex panel interactions

Design advanced user-driven actions, such as dynamically resizing an app panel or adjusting instrument cluster views based on main display content.

Define custom Events to trigger specific, non-system-standard Transitions.

Extend IVI layouts to a Unified Digital Cockpit

While Scalable UI manages multi-panel windowing (TaskPanel and DecorPanel) on the infotainment display (display0) in the SDV IVI guest VM, OEMs can pair Scalable UI with AAOS Display Safety to adjust instrument cluster views based on main display content and deliver a safety-isolated Unified Digital Cockpit across the center stack and instrument cluster:

  • Scalable UI event-to-action triggers (SDV IVI VM): When a panel state changes on the main infotainment display, Scalable UI can dispatch an ordered broadcast intent using an <Action> in xml/scalable_ui_actions.xml (see Configure an action) to notify cluster components of layout, navigation, or mode changes.
  • DriverUI (SDV IVI VM): Runs on the cluster display surface (display1) as a privileged Android system app launched by ClusterHomeManager (Cluster2) and built with Automotive Design for Compose. DriverUI renders non-safety cluster views (such as navigation maps, media playback, and telephony) and handles state transitions from the IVI system.
  • IVI-to-Display-Safety gRPC bridge (SDV Gateway on IVI): DriverUI uses the SDV Gateway Client (SdvGatewayClient / ISdvGateway) to discover the High availability renderer (HAR) and establish a cross-VM gRPC ManagedChannel (driverui.proto) over the SDV-RPC interface. Through this channel, DriverUI sends RPCs such as ChangeVariant (to swap Figma node variants in the cluster), DocumentSwitched, DesignTokenUpdate (themes), LocaleUpdate, and periodic Heartbeat messages.
  • HAR and Safety Monitor (SDV Media VM): Run in an isolated, rapid-boot VirtIO guest VM to render early-boot and ASIL-B safety-critical elements (such as speed, gear, telltales, audible chimes, and rear-view camera feeds). When HAR receives active Heartbeat RPCs from DriverUI, it sets the Android cluster regions to transparent to blend DriverUI content with HAR safety overlays; if SDV IVI is booting or unavailable, HAR renders opaque fallback placeholders.
  • What OEMs need to configure: To integrate this flow, OEMs configure panel <Event> triggers and <Action> intents in xml/scalable_ui_actions.xml on SDV IVI, customize the Figma design document and Config.json signal-to-node mappings for the Safety design toolchain, and implement the HAR Platform Abstraction Layer (PAL) traits for target display, audio, camera, and vehicle bus signals.