Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release
, bukan aosp-main
, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.
Pengelolaan framebuffer klien
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Mulai Android 13, framebuffer baru, yang digunakan selama
komposisi
klien, dialokasikan setiap kali resolusi layar berubah. Alokasi
ini dilakukan oleh SurfaceFlinger pada siklus invalidate berikutnya
setelah perubahan resolusi.
Pengelolaan framebuffer selama pengalihan resolusi
Perubahan resolusi terjadi karena salah satu dari dua
skenario berikut:
Peristiwa hotplug,
yang dimulai oleh Hardware Composer (HWC), yang terjadi saat beralih dari satu tampilan
eksternal ke tampilan eksternal lain yang memiliki resolusi default yang berbeda.
Selama peristiwa hotplug, handle ke framebuffer lama akan dirilis
saat data tampilan lama dide-alokasikan.
Tombol mode tampilan yang dimulai oleh SurfaceFlinger, yang terjadi saat
pengguna mengubah resolusi dengan setelan pengguna,
atau aplikasi mengubah resolusi dengan preferredDisplayModeId
.
Selama pengalihan mode tampilan, handle ke framebuffer klien yang ada
dirilis oleh SurfaceFlinger sebelum memanggil setActiveConfig
atau setActiveConfigWithConstraints
.
Untuk menghindari masalah yang parah, seperti fragmentasi memori, pada perangkat yang
tidak menyediakan memori yang cukup untuk framebuffer lama dan baru, sangat penting
agar HWC berhenti menggunakan framebuffer lama dan melepaskan
handle apa pun ke framebuffer ini seperti yang ditunjukkan dalam kasus berikut:
Dengan melepaskan handle, memori framebuffer dapat dide-alokasikan sepenuhnya
sebelum alokasi framebuffer baru yang dilakukan SurfaceFlinger
selama siklus invalidate berikutnya.
Rekomendasi untuk pengelolaan framebuffer
Jika HWC tidak melepaskan handle ke framebuffer lama tepat waktu,
alokasi framebuffer baru akan dilakukan sebelum penghapusan
alokasi framebuffer lama. Hal ini dapat menyebabkan masalah besar saat alokasi baru gagal
karena fragmentasi atau masalah lainnya. Lebih buruk lagi, jika
HWC tidak melepaskan handle ini sama sekali, kebocoran memori dapat
terjadi.
Untuk menghindari kegagalan alokasi yang fatal, ikuti rekomendasi berikut:
Jika HWC perlu terus menggunakan framebuffer klien lama hingga framebuffer klien
baru disediakan, Anda harus mencadangkan memori yang cukup
untuk framebuffer lama dan baru, dan mungkin menjalankan algoritma
defragmentasi di ruang memori framebuffer.
Alokasikan kumpulan memori khusus untuk framebuffer yang terpisah dari
sebagian besar memori buffer grafis. Hal ini penting karena antara
pembatalan alokasi dan realokasi framebuffer, proses pihak ketiga dapat
mencoba mengalokasikan memori grafis. Jika kumpulan memori grafis yang sama
digunakan oleh framebuffer dan jika memori grafis penuh, proses
pihak ketiga dapat menempati memori grafis yang sebelumnya dialokasikan oleh framebuffer,
sehingga memori yang tersedia tidak cukup untuk realokasi framebuffer atau, mungkin
memfragmentasi ruang memori.
Menguji pengelolaan framebuffer
OEM disarankan untuk menguji pengelolaan memori framebuffer klien yang tepat di seluruh
tombol resolusi untuk perangkat mereka, yang dijelaskan sebagai berikut:
Untuk peristiwa hotplug, cukup cabut dan hubungkan kembali dua layar yang berbeda dengan
resolusi yang berbeda.
Untuk pengalihan mode, gunakan pengujian Verifier
CTS ModeSwitchingTestActivity
untuk memulai pengalihan mode guna menguji perilaku memori framebuffer.
Pengujian ini dapat mengidentifikasi masalah secara visual yang sulit dideteksi
secara terprogram.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]