Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
Hardware Composer HAL
Stay organized with collections
Save and categorize content based on your preferences.
The Hardware Composer (HWC) HAL determines the most efficient
way to composite buffers with the available hardware. As a HAL, its
implementation is device-specific and usually done by the display hardware OEM.
The value of this approach is easy to recognize when you consider overlay
planes, which composite multiple buffers in
the display hardware rather than the GPU. For example, consider a typical
Android phone in portrait orientation, with the status bar on top, navigation
bar at the bottom, and app content everywhere else. The contents for each layer
are in separate buffers. You can handle composition using either of the
following methods:
- Rendering the app content into a scratch buffer, then rendering the status
bar over it, the navigation bar on top of that, and finally passing the scratch
buffer to the display hardware.
- Passing all three buffers to the display hardware and instructing it to read data
from different buffers for different parts of the screen.
The latter approach can be significantly more efficient.
Display processor capabilities vary significantly. The number of overlays,
whether layers can be rotated or blended, and restrictions on positioning and
overlap can be difficult to express through an API. To accommodate these options, the HWC performs
following calculations:
- SurfaceFlinger provides HWC with a full list of layers and asks, "How do
you want to handle this?"
- HWC responds by marking each layer as device or client composition.
- SurfaceFlinger takes care of any client, passing the output buffer
to HWC, and lets HWC handle the rest.
Because hardware vendors can custom tailor decision-making code, it's possible
to get the best performance out of every device.
Overlay planes may be less efficient than GL composition when nothing on the
screen is changing. This is particularly true when overlay contents have
transparent pixels and overlapping layers are blended. In such cases,
the HWC can request GLES composition for some or all layers and retain
the composited buffer. If SurfaceFlinger asks to composite the same
set of buffers, the HWC can show the previously composited scratch
buffer. This can improve the battery life of an idle device.
Android devices typically support four overlay planes.
Attempting to composite more layers than overlays causes the system to use GLES
composition for some of them, meaning the number of layers used by an app can
have a measurable impact on power consumption and performance.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-06-12 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-06-12 UTC."],[],[],null,["# Hardware Composer HAL\n\nThe Hardware Composer (HWC) HAL determines the most efficient\nway to composite buffers with the available hardware. As a HAL, its\nimplementation is device-specific and usually done by the display hardware OEM.\n\nThe value of this approach is easy to recognize when you consider *overlay\nplanes*, which composite multiple buffers in\nthe display hardware rather than the GPU. For example, consider a typical\nAndroid phone in portrait orientation, with the status bar on top, navigation\nbar at the bottom, and app content everywhere else. The contents for each layer\nare in separate buffers. You can handle composition using either of the\nfollowing methods:\n\n- Rendering the app content into a scratch buffer, then rendering the status bar over it, the navigation bar on top of that, and finally passing the scratch buffer to the display hardware.\n- Passing all three buffers to the display hardware and instructing it to read data from different buffers for different parts of the screen.\n\nThe latter approach can be significantly more efficient.\n\nDisplay processor capabilities vary significantly. The number of overlays,\nwhether layers can be rotated or blended, and restrictions on positioning and\noverlap can be difficult to express through an API. To accommodate these options, the HWC performs\nfollowing calculations:\n\n1. SurfaceFlinger provides HWC with a full list of layers and asks, \"How do you want to handle this?\"\n2. HWC responds by marking each layer as device or client composition.\n3. SurfaceFlinger takes care of any client, passing the output buffer to HWC, and lets HWC handle the rest.\n\nBecause hardware vendors can custom tailor decision-making code, it's possible\nto get the best performance out of every device.\n\nOverlay planes may be less efficient than GL composition when nothing on the\nscreen is changing. This is particularly true when overlay contents have\ntransparent pixels and overlapping layers are blended. In such cases,\nthe HWC can request GLES composition for some or all layers and retain\nthe composited buffer. If SurfaceFlinger asks to composite the same\nset of buffers, the HWC can show the previously composited scratch\nbuffer. This can improve the battery life of an idle device.\n\nAndroid devices typically support four overlay planes.\nAttempting to composite more layers than overlays causes the system to use GLES\ncomposition for some of them, meaning the number of layers used by an app can\nhave a measurable impact on power consumption and performance."]]
