A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release
anziché aosp-main
per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Gestione del framebuffer del client
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
A partire da Android 13, i nuovi framebuffer, utilizzati durante la composizione
client, vengono allocati ogni volta che cambia la risoluzione del display. Questa allocazione viene eseguita da SurfaceFlinger nel ciclo invalidate successivo dopo una modifica della risoluzione.
Gestione del framebuffer durante i cambi di risoluzione
Le modifiche alla risoluzione si verificano in uno dei seguenti due scenari:
Un evento hotplug, avviato da Hardware Composer (HWC), che si verifica quando si passa da un display esterno a un altro con una risoluzione predefinita diversa.
Durante un evento hotplug, gli handle dei vecchi frame buffer vengono rilasciati quando i vecchi dati di visualizzazione vengono deallocati.
Un passaggio alla modalità di visualizzazione avviato da SurfaceFlinger, che si verifica quando l'utente modifica la risoluzione con le impostazioni utente o un'app modifica la risoluzione con preferredDisplayModeId
.
Durante il passaggio da una modalità di visualizzazione all'altra, gli handle dei framebuffer client esistenti vengono rilasciati da SurfaceFlinger prima di chiamare setActiveConfig
o setActiveConfigWithConstraints
.
Per evitare problemi catastrofici, come la frammentazione della memoria, sui dispositivi che
non riservano memoria sufficiente per i framebuffer vecchi e nuovi, è fondamentale
che HWC cessi di utilizzare i framebuffer vecchi e rilasci gli eventuali
handle a questi framebuffer come mostrato nei seguenti casi:
Il rilascio degli handle consente di deallocare completamente la memoria del framebuffer
prima dell'allocazione di nuovi framebuffer eseguita da SurfaceFlinger
durante il successivo ciclo di invalidate.
Consigli per la gestione del framebuffer
Se HWC non rilascia in tempo i handle per i vecchi frame buffer,
la nuova allocazione del frame buffer avviene prima della deallocazione del vecchio
frame buffer. Ciò può causare problemi catastrofici quando la nuova allocazione non va a buon fine
a causa di frammentazione o altri problemi. Inoltre, se HWC non rilascia affatto questi handle, è possibile che si verifichi una perdita di memoria.
Per evitare errori di allocazione catastrofici, segui questi consigli:
Se l'HWC deve continuare a utilizzare i vecchi framebuffer client fino a quando non vengono forniti i nuovi framebuffer client, è fondamentale riservare memoria sufficiente sia per i framebuffer vecchi che per quelli nuovi ed eventualmente eseguire algoritmi di defragmentazione nello spazio di memoria del framebuffer.
Alloca un pool di memoria dedicato per i framebuffer separato dal resto della memoria del buffer grafico. Questo è importante perché tra la deallocazione e la riallocazione dei framebuffer, un processo di terze parti può tentare di allocare la memoria grafica. Se lo stesso pool di memoria grafica viene utilizzato dal framebuffer e se la memoria grafica è piena, il processo di terze parti può occupare la memoria grafica precedentemente allocata da un framebuffer, lasciando quindi una memoria insufficiente per la riallocazione del framebuffer o, eventualmente, frammentando lo spazio di memoria.
Testa la gestione del framebuffer
Gli OEM sono invitati a verificare la corretta gestione della memoria del framebuffer del client per gli switch di risoluzione del proprio dispositivo, come descritto di seguito:
Per gli eventi hotplug, scollega e ricollega due display diversi con risoluzioni diverse.
Per i cambi di modalità, utilizza il test ModeSwitchingTestActivity
CTS
Verifier per avviare un cambio di modalità per testare il comportamento della memoria del framebuffer.
Questo test può identificare visivamente i problemi difficili da rilevare
programmaticamente.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-27 UTC."],[],[],null,["# Client framebuffer management\n\nStarting with Android 13, new framebuffers, used during\n[client](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/DisplayCommand.aidl#113)\ncomposition, are allocated whenever the display resolution changes. This\nallocation is performed by SurfaceFlinger on the next *invalidate* cycle\nafter a resolution change.\n\nFramebuffer management during resolution switches\n-------------------------------------------------\n\nResolution changes occur due to one of the following\ntwo scenarios:\n\n- A [hotplug event](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerCallback.aidl#41),\n initiated by Hardware Composer (HWC), which occurs when swapping from one external\n display to a different external display that has a different default resolution.\n\n During a hotplug event, the handles to the old framebuffers are released\n when the old display data is deallocated.\n- A display mode switch initiated by SurfaceFlinger, which occurs when the\n user changes the resolution with [user settings](https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android16-release/core/java/android/hardware/display/DisplayManager.java#1209),\n or an app changes the resolution with [`preferredDisplayModeId`](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#preferredDisplayModeId).\n\n During a display mode switch, the handles to existing client framebuffers\n are released by SurfaceFlinger before calling [`setActiveConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#550)\n or [`setActiveConfigWithConstraints`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#577).\n\nTo avoid catastrophic problems, such as memory fragmentation, on devices that\ndon't reserve enough memory for the old and new framebuffers, it's critical\nthat HWC ceases to use the old framebuffers and releases any\nhandles to these framebuffers as shown in the following cases:\n\n- For hotplug events, immediately before calling [`onHotplug`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerCallback.aidl#41).\n\n- For mode switches, immediately after the call to [`setActiveConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#550)\n or [`setActiveConfigWithConstraints`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#577).\n\nReleasing the handles allows the framebuffer memory to be fully deallocated\nprior to the allocation of new framebuffers that SurfaceFlinger performs\nduring the next *invalidate* cycle.\n\n### Recommendations for framebuffer management\n\nIf HWC doesn't release handles to old framebuffers in time,\nthe new framebuffer allocation takes place before the old framebuffer\ndeallocation. This can cause catastrophic problems when the new allocation fails\ndue to fragmentation or other issues. Even worse, if\nHWC doesn't release these handles at all, a memory leak can\noccur.\n\nTo avoid catastrophic allocation failures, follow these recommendations:\n\n- If HWC needs to continue using the old client framebuffers until the new\n client framebuffers are provided, then it's critical to reserve enough memory\n for both the old and new framebuffers, and possibly run defragmentation\n algorithms on the framebuffer memory space.\n\n- Allocate a dedicated memory pool for the framebuffers that's separate from\n the rest of the graphic buffer memory. This is important because between\n deallocation and reallocation of the framebuffers, a third-party process can\n attempt to allocate graphics memory. If the same graphics memory pool is\n used by the framebuffer and if the graphics memory is full, the third-party\n process can occupy the graphics memory previously allocated by a framebuffer,\n thus leaving insufficient memory for the framebuffer reallocation or, possibly\n fragmenting the memory space.\n\nTest framebuffer management\n---------------------------\n\nOEMs are advised to test for proper client framebuffer memory management across\nresolution switches for their device, described as follows:\n\n- For hotplug events, simply unplug and reconnect two different displays with\n different resolutions.\n\n- For mode switches, use the [`ModeSwitchingTestActivity`](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/apps/CtsVerifier/src/com/android/cts/verifier/tv/display/ModeSwitchingTestActivity.java;l=47-53;drc=c80d948aff1e7df5c2dc0ddba0d1cd63a90e4d9c) CTS\n Verifier test to initiate a mode switch for testing framebuffer memory behavior.\n This test can visually identify problems that are hard to detect\n programmatically."]]