Ab Android 13 wird der Hardware Composer (HWC) HAL in
AIDL und die HIDL-Versionen verschiedener
android.hardware.graphics.composer@2.1
bis
android.hardware.graphics.composer@2.4
wurden verworfen.
Auf dieser Seite werden die Unterschiede zwischen AIDL und HIDL HAL für die HWC sowie die Implementierung und Tests von AIDL HAL
Aufgrund der Vorteile von AIDL, Anbietern wird ermutigt, die AIDL Composer HAL wird gestartet Android 13 anstelle der HIDL-Version. Weitere Informationen finden Sie in der Implementierung.
Unterschiede zwischen AIDL und HIDL HALs
Der neue AIDL Composer HAL mit dem Namen android.hardware.graphics.composer3
ist
definiert in IComposer.aidl
.
Es macht ein API verfügbar, das dem HIDL HAL ähnelt.
android.hardware.graphics.composer@2.4
mit den folgenden Änderungen:
Entfernung der Fast Message Queue (FMQ) in parzellen Befehle zu bevorzugen.
AIDL HAL definiert die Befehlsschnittstelle anhand von stark typisierten Pakettypen im Gegensatz zu den serialisierten Befehlen über FMQ in HIDL. Dieses bietet eine stabile Schnittstelle für Befehle und eine besser lesbare Definition, wird die Befehlsnutzlast interpretiert.
Die
executeCommands
Methode ist inIComposerClient.aidl
definiert alsCommandResultPayload[] executeCommands(in DisplayCommand[] commands);
Dabei ist jeder Befehl ein stark typisierter, parzellenbarer Typ, der in
DisplayCommand.aidl
Befehlsantworten sind stark typisierte Parcelables, die inCommandResultPayload.aidl
IComposerClient.getClientTargetSupport
wurde entfernt, da für diese Methode keine aktiven Clients vorhanden sind.Darstellung von Farben als Gleitkommazahlen statt als Bytes, um sie besser mit dem oberer Grafikstapel in Android gemäß der Definition in
ASurfaceTransaction_setColor
.Es wurden neue Felder zur Steuerung von HDR-Inhalten hinzugefügt.
In AIDL HAL unterstützen gemischte SDR-/HDR-Schichtstapel das nahtlose Dimmen von SDR-Ebenen werden eingeblendet, wenn eine HDR-Ebene gleichzeitig auf dem Bildschirm zu sehen ist.
Das Feld
brightness
inLayerCommand
kann SurfaceFlinger eine Helligkeit pro Schicht festlegen, sodass HWC die im linearen Lichtraum und nicht im Gammaraum.Das Feld
brightness
inClientTargetPropertyWithBrightness
kann die HWC den Helligkeitsbereich für die ClientzusammensetzungRenderEngine
anweisen ob SDR-Schichten bei der Clientzusammensetzung gedimmt werden sollen.Die
dimmingStage
kann die HWC konfigurieren, wannRenderEngine
Inhalte dimmen soll. Dieses unterstützt anbieterdefinierteColorModes
, die möglicherweise in Gamma gedimmt werden sollen um anbieterdefinierte Kontrastverbesserungen in seinen Farbpipelines zu ermöglichen.Hinzufügung eines neuen Kompositionstyps
DISPLAY_DECORATION
inComposition.aidl
für Bildschirmdekorationen.Einige Geräte verfügen über spezielle Hardware, um das Zeichnen der Alphamaske zu optimieren, Glättet abgerundete Ecken und Aussparungen auf Displays. Geräte mit solcher Hardware müssen
IComposerClient.getDisplayDecorationSupport
implementieren um eineDisplayDecorationSupport
-Struktur zurückzugeben, wie sie im neuenDisplayDecorationSupport.aidl
Diese Struktur beschreibt diePixelFormat
undAlphaInterpretation
Für das Gerät erforderliche Aufzählungen Bei dieser Implementierung markiert die System-UI die Alphamaskenebene alsDISPLAY_DECORATION
, einen neuen Kompositionstyp, der die dedizierte Hardware nutzt.Hinzufügen eines neuen
expectedPresentTime
aufDisplayCommand.aidl
.Mit dem Feld
expectedPresentTime
kann SurfaceFlinger den Zeit, bis der aktuelle Inhalt auf dem Bildschirm angezeigt werden muss. Damit sendet SurfaceFlinger einen Befehl an die Implementierung, bevor Zeit verlagern, sodass mehr Kompositionsarbeiten ausgeführt werden können.Neue APIs zur Steuerung der Boot-Anzeigekonfiguration hinzugefügt.
Mit
BOOT_DISPLAY_CONFIG
Anbieter können angeben, dass die Konfiguration der Bootanzeige unterstützt wird. DiesetBootDisplayConfig
,clearBootDisplayConfig
, undgetPreferredBootDisplayConfig
verwendenBOOT_DISPLAY_CONFIG
wie folgt:Mit
setBootDisplayConfig
informiert das Framework Anbieter über die Anzeigekonfiguration beim Start. Anbieter muss in der Konfiguration der Bootanzeige im Cache gespeichert und am nächsten neu starten. Wenn das Gerät in dieser Konfiguration nicht gestartet werden kann, muss der Anbieter eine Konfiguration, die der Auflösung und Aktualisierungsrate dieser Konfiguration entspricht. Falls keine Konfiguration vorhanden ist, sollte der Anbieter seine bevorzugte Anzeigekonfiguration verwenden.Mit
clearBootDisplayConfig
informiert das Framework die Anbieter, die Konfiguration der Bootanzeige zu löschen beim nächsten Neustart mit der bevorzugten Anzeigekonfiguration starten.Mit
getPreferredBootDisplayConfig
das Framework den bevorzugten Bootmodus des Anbieters abfragt.
Wenn die Konfiguration der Startanzeige nicht unterstützt wird, geben diese Methoden eine Fehlermeldung Wert von
UNSUPPORTED
.Neue APIs zur Steuerung des Inaktivitäts-Timers des Displays hinzugefügt.
Mit
DISPLAY_IDLE_TIMER
Anbieter können angeben, dass vom Anbieter ein Inaktivitäts-Timer für auf diesem Display. Bei Inaktivität stellt diese Funktion die Aktualisierungsrate auf eine niedrigere um den Akku zu schonen. Die Plattform verwendetsetIdleTimerEnabled
um das Zeitlimit des Timers zu steuern oder um ihn zu deaktivieren, um bei Inaktivität die Aktualisierungsrate umzuschalten.IComposerCallback.onVsyncIdle
verwenden -Callback zeigt der Plattform an, dass der Bildschirm inaktiv ist und dievsync
die Frequenz geändert. Die Plattform reagiert auf diesen Callback, indem sie ihre Modellvsync
. Er erzwingt eine Neusynchronisierung vonvsync
mit dem nächsten Frame und lernt, Schrittfrequenz:vsync
.
Implementierung
Anbieter müssen die AIDL HAL für Android 13 nicht implementieren. Sie können jedoch wird empfohlen, die AIDL Composer-HAL anstelle der HIDL-Version, um die neuen Funktionen und APIs zu verwenden.
Eine Referenzimplementierung für AIDL HWC HAL in Android-Emulatoren implementiert ist.
Testen
Führen Sie VtsHalGraphicsComposer3_TargetTest
aus, um die Implementierung zu testen.