Advanced AOSP Subsystems
3 min read

Display HAL

Overview

The Display Hardware Abstraction Layer (HAL) bridges the gap between Android's SurfaceFlinger and the vendor-specific display drivers. Primarily exposed through the Hardware Composer (HWC) HIDL/AIDL interfaces, the Display HAL is responsible for compositing layers, managing display power states, and applying color transformations.

Hardware Composer (HWC) HAL

The core of the Display HAL is the HWC. Instead of SurfaceFlinger using OpenGL ES or Vulkan to composite every frame (which consumes significant GPU power), SurfaceFlinger asks the HWC to composite the layers directly in the display controller hardware.

HWC Capabilities

  • Hardware Overlays: The display controller has multiple hardware planes. HWC assigns Android Surface layers to these planes.
  • Client vs. Device Composition:
    • Device Composition: The HWC handles the composition (ideal for performance and power).
    • Client Composition: The HWC rejects the layer mapping (usually because there are too many layers or unsupported blending), forcing SurfaceFlinger (the "Client") to composite the layers using the GPU.

Display HAL Interface for Brightness and Color

Beyond composition, the Display HAL manages the physical characteristics of the panel.

Brightness Control

Brightness is managed via the IComposerClient interface or the dedicated Lights HAL (and more recently, the Backlight HAL). The system sends a float value (0.0 to 1.0) or an integer backlight value to the HAL.

// Example: Setting display brightness in HWC
Return<Error> setDisplayBrightness(Display display, float brightness) {
    if (brightness < 0.0f || brightness > 1.0f) {
        return Error::BAD_PARAMETER;
    }
    // Write to sysfs node (e.g., /sys/class/backlight/panel0-backlight/brightness)
    writeSysfsNode(BACKLIGHT_PATH, convertToHardwareScale(brightness));
    return Error::NONE;
}

Color Mode Configuration

Modern Android devices support various color modes, such as sRGB, DCI-P3, and Adobe RGB. SurfaceFlinger queries the HWC for supported ColorMode and RenderIntent pairs.

  • ColorMode: Defines the gamut (e.g., ColorMode::DISPLAY_P3).
  • RenderIntent: Defines how colors outside the gamut are mapped (e.g., RenderIntent::COLORIMETRIC).

When the user changes the display settings, or when HDR content is playing, SurfaceFlinger calls setColorMode on the HWC.

HDR Capabilities

High Dynamic Range (HDR) requires strict coordination between the media decoder, SurfaceFlinger, and the Display HAL.

  1. Metadata Passing: MediaCodec extracts HDR metadata (like SMPTE ST 2086 mastering display data or HDR10+ dynamic metadata).
  2. SurfaceFlinger: Attaches this metadata to the specific layer.
  3. HWC Consumption: The Display HAL reads the PerFrameMetadata for that layer.
  4. Panel Configuration: The HAL configures the display controller to switch into HDR mode, adjusting the electro-optical transfer function (EOTF) and pushing the backlight to maximum brightness while adjusting pixel values to prevent clipping.

Dumpsys for HDR and Color

You can inspect the current color modes and HDR capabilities supported by the HAL via:

adb shell dumpsys SurfaceFlinger | grep -A 10 "Display 0 HWC state"

Look for lines detailing colorMode, supportedColorModes, and hdrTypes.

The Backlight HAL

In recent Android versions, panel brightness control has been modularized. The traditional approach involved the Lights HAL modifying /sys/class/backlight. To provide more synchronized brightness transitions (especially during VRrr or low-framerate compensation), the backlight control logic is increasingly integrated directly into the display pipeline via specific vendor HALs or extended HWC commands.