Starting with Android 13, the system allocates new framebuffers, used during client composition, whenever the display resolution changes. SurfaceFlinger performs this allocation on the next invalidate cycle after a resolution change.
Framebuffer management during resolution switches
Resolution changes occur due to one of the following two scenarios:
A hotplug event, initiated by the Hardware Composer (HWC), that occurs when swapping from one external display to a different external display that has a different default resolution.
During a hotplug event, HWC releases the handles to the old framebuffers when it deallocates the old display data.
A display mode switch initiated by SurfaceFlinger, that occurs when you change the resolution using user settings, or an app changes the resolution using
preferredDisplayModeId.During a display mode switch, SurfaceFlinger releases the handles to existing client framebuffers before calling
setActiveConfigorsetActiveConfigWithConstraints.
To prevent catastrophic issues like memory fragmentation on devices without sufficient framebuffer memory, HWC must release handles to old framebuffers. This is critical in the following cases:
For hotplug events, immediately before calling
onHotplug.For mode switches, immediately after calling
setActiveConfigorsetActiveConfigWithConstraints.
Releasing the handles allows the framebuffer memory to be fully deallocated before SurfaceFlinger allocates new framebuffers during the next invalidate cycle.
Recommendations for framebuffer management
If HWC doesn't release handles to old framebuffers in time, new framebuffer allocation occurs before old framebuffer deallocation. This can cause catastrophic problems when the new allocation fails due to fragmentation or other issues. Even worse, if HWC doesn't release these handles at all, a memory leak can occur.
To avoid catastrophic allocation failures, follow these recommendations:
If HWC needs to continue using the old client framebuffers until new client framebuffers are provided, it's critical to reserve enough memory for both the old and new framebuffers, and possibly run defragmentation algorithms on the framebuffer memory space.
Allocate a dedicated memory pool for the framebuffers that's separate from the rest of the graphic buffer memory. This is important because a third-party process might attempt to allocate graphics memory between framebuffer deallocation and reallocation. If the framebuffer uses the same graphics memory pool and if the graphics memory is full, the third-party process can occupy memory previously allocated by a framebuffer. This can lead to insufficient memory for framebuffer reallocation or memory fragmentation.
Test framebuffer management
OEMs are advised to test for proper client framebuffer memory management across resolution switches for their device, described as follows:
For hotplug events, unplug and reconnect two different displays that have different resolutions.
For mode switches, use the
ModeSwitchingTestActivityCTS Verifier test to initiate a mode switch for testing framebuffer memory behavior. This test can visually identify problems that are hard to detect programmatically.