DisplayManagerService (DMS) in Android: Architecture and Implementation Analysis
The Android DisplayManagerService (DMS) orchestrates detection, addition, configuration, and removal of physical and logical displays, handling multi‑user, virtual, split‑screen, foldable, and HDR scenarios through components such as DisplayDeviceRepository, LogicalDisplayMapper, adapters, and power controllers, all initialized by SystemServer.
DisplayManagerService (DMS) is the core service in Android systems responsible for managing display devices. In early Android versions, display management was primarily handled by SurfaceFlinger and WindowManagerService (WMS), with DMS only managing basic display devices and loading related configurations.
DMS Evolution Across Android Versions:
Android 4.2 introduced multi-user support, where each user could have independent display configurations and support for multiple display devices (such as HDMI external monitors). Android 6 added support for virtual screens and screen casting to facilitate developer debugging. Android 7 and Android 8 increased support for split-screen and multi-window modes, with DMS managing display and interaction for these smaller windows. Android 10 introduced support for foldable devices that can switch between unfolded and folded states, requiring DMS to handle these display形态 changes and map physical screens to correct logical displays. Android 13 added support for Ultra HDR resources, enabling Android devices to better process and display high dynamic range content, with DMS responsible for HDR brightness logic and strategies.
DMS Role in Display System:
DMS performs five key functions: (1) Detecting, adding, and removing display devices - monitoring and detecting new display device connections; (2) Creating and managing logical displays - providing a flexible intermediate layer to manage one or more physical display devices; (3) Adjusting display device parameters including screen state, brightness, resolution, refresh rate, display orientation, and display area; (4) Managing multi-display device state switching - handling connection, disconnection, and switching between physical display devices; (5) Event notification - promptly notifying other system components like WMS and applications when display device states change.
Key Components:
The content describes physical displays (from SurfaceFlinger, representing real physical screens with different attributes) and logical displays (relative to physical screens, focusing on different logical settings, affected by applications and WMS modules). Each physical screen corresponds to a logical screen, while one logical screen can correspond to one or multiple physical screens.
Key classes include: DisplayManagerService (core display management), DisplayManagerInternal (internal API for system components), DisplayManager (external API for apps), DisplayManagerGlobal (singleton implementation), DisplayDevice (represents physical display devices), DisplayDeviceRepository (manages all DisplayDevice and monitors physical screen changes), LogicalDisplay (upper-layer abstraction managing physical devices), LogicalDisplayMapper (manages all LogicalDisplay and handles mapping in multi-screen devices), DisplayAdapter (screen adapters for different physical displays), and DisplayPowerController (manages display state and brightness).
DMS Startup Process:
DMS is started by SystemServer process. The constructor creates UI handle and display handle for processing display events, instantiates mDisplayDeviceRepo and mLogicalDisplayMapper, and loads default configurations. The onStart method implements binder service and local service interfaces, registers display listeners, and attempts to connect to the default display via SurfaceControl. After startup, DMS receives PHASE_WAIT_FOR_DEFAULT_DISPLAY notification to obtain default display and virtual display adapter. Finally, systemReady completes initialization including updating user HDR settings and registering callbacks.
DisplayDevice Lifecycle Management:
The content details four phases: Detection - DMS creates display adapters, detects devices, and registers listeners; Addition - DisplayDeviceRepository adds device to list and notifies LogicalDisplayMapper, which creates corresponding LogicalDisplay via createNewLogicalDisplayLocked, binds with displayID, layerStack, and DisplayDevice; Update - Triggered by screen state changes, HDR brightness ratio changes, refresh rate/resolution changes, or color mode changes, with LocalDisplayAdapter clearing DisplayDeviceInfo and notifying LogicalDisplayMapper to update; Removal - LocalDisplayAdapter removes corresponding DisplayDevice via tryDisconnectDisplayLocked and sends removal messages to destroy objects.
OPPO Kernel Craftsman
Sharing Linux kernel-related cutting-edge technology, technical articles, technical news, and curated tutorials
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.