AIDL für Hardware Composer HAL

Ab Android 13 wird die HAL des Hardware-Composers (HWC) in AIDL definiert. Die HIDL-Versionen von android.hardware.graphics.composer@2.1 bis android.hardware.graphics.composer@2.4 werden eingestellt.

Auf dieser Seite werden die Unterschiede zwischen AIDL und dem HIDL HAL für die HWC sowie die Implementierung und das Testen von AIDL HAL beschrieben.

Aufgrund der Vorteile von AIDL wird Anbietern empfohlen, ab Android 13 den AIDL Composer HAL anstelle der HIDL-Version zu implementieren. Weitere Informationen finden Sie im Abschnitt Implementierung.

Unterschiede zwischen AIDL und HIDL HALs

Die neue HAL für den AIDL-Kompiler, android.hardware.graphics.composer3, ist in IComposer.aidl definiert. Er stellt eine API, die dem HIDL HAL android.hardware.graphics.composer@2.4 ähnelt, mit den folgenden Änderungen zur Verfügung:

  • Die Schnellnachrichtenwarteschlange (Fast Message Queue, FMQ) wurde zugunsten von parzellierbaren Befehlen entfernt.

    Die AIDL HAL definiert die Befehlsschnittstelle basierend auf stark typisierten, parzellierbaren Typen im Gegensatz zu den serialisierten Befehlen über FMQ in HIDL. Dadurch erhalten Sie eine stabile Schnittstelle für Befehle und eine besser lesbare Definition dafür, wie die Befehlsnutzlast interpretiert wird.

    Die Methode executeCommands ist in IComposerClient.aidl so definiert:

    CommandResultPayload[] executeCommands(in DisplayCommand[] commands);

    wobei jeder Befehl ein stark typisierter, paketbarer Typ ist, der in DisplayCommand.aidl definiert ist. Befehlsantworten sind stark typisierte Parcelables, die in CommandResultPayload.aidl definiert sind.

  • IComposerClient.getClientTargetSupport wurde entfernt, da für diese Methode keine aktiven Clients vorhanden sind.

  • Darstellung von Farben als Gleitkommazahlen statt als Byte, um sie besser mit dem oberen Grafikstack in Android abzustimmen (Definition in ASurfaceTransaction_setColor).

  • Es wurden neue Felder zur Steuerung von HDR-Inhalten hinzugefügt.

    In der AIDL HAL unterstützen gemischte SDR/HDR-Ebenenstapel das nahtlose Dimmen von SDR-Ebenen, wenn gleichzeitig eine HDR-Ebene auf dem Bildschirm angezeigt wird.

    Mit dem Feld brightness in LayerCommand kann SurfaceFlinger eine Helligkeit pro Ebene angeben, damit der HWC den Inhalt der Ebene im linearen Lichtraum abdimmt, im Gegensatz zum Gammaraum.

    Mit dem Feld brightness in ClientTargetPropertyWithBrightness kann der HWC den Helligkeitsbereich für die Clientkomposition angeben und RenderEngine anweisen, ob SDR-Ebenen in der Clientkomposition gedimmt werden sollen.

    Mit dem Feld dimmingStage kann die HWC konfigurieren, wann RenderEngine Inhalte dimmen soll. Dies eignet sich für anbieterdefinierte ColorModes, die es vorziehen, im Gammabereich zu dimmen, um anbieterdefinierte Kontrastverbesserungen in ihren Farbpipelines zu ermöglichen.

  • Es wurde ein neuer Kompositionstyp DISPLAY_DECORATION in Composition.aidl für Bildschirmdekorationen hinzugefügt.

    Einige Geräte haben spezielle Hardware, um das Zeichnen der Alphamaske zu optimieren, die abgerundete Ecken und Ausschnitte auf Displays glättet. Geräte mit solcher Hardware müssen IComposerClient.getDisplayDecorationSupport implementieren, um eine DisplayDecorationSupport-Struktur wie in der neuen DisplayDecorationSupport.aidl definiert zurückzugeben. Diese Struktur beschreibt die für das Gerät erforderlichen PixelFormat- und AlphaInterpretation-Enums. Bei dieser Implementierung markiert die System-UI die Alphamaskenebene als DISPLAY_DECORATION. Dies ist ein neuer Zusammensetzungstyp, der die dedizierte Hardware nutzt.

  • Zusätzliches neues expectedPresentTime-Feld zu DisplayCommand.aidl.

    Mit dem Feld expectedPresentTime kann SurfaceFlinger die voraussichtliche aktuelle Zeit auf den Zeitpunkt festlegen, zu dem der aktuelle Inhalt auf dem Bildschirm angezeigt werden muss. Mit dieser Funktion sendet SurfaceFlinger im Voraus einen vorhandenen Befehl an die Implementierung, damit ein größerer Teil der Kompositionsarbeit in einer Pipeline verarbeitet werden kann.

  • Neue APIs zur Steuerung der Boot-Anzeigekonfiguration hinzugefügt.

    Mit BOOT_DISPLAY_CONFIG können Anbieter angeben, dass die Konfiguration der Bootanzeige unterstützt wird. Die Methoden setBootDisplayConfig, clearBootDisplayConfig und getPreferredBootDisplayConfig verwenden BOOT_DISPLAY_CONFIG so:

    • Über setBootDisplayConfig informiert das Framework die Anbieter über die Konfiguration der Anzeige zur Bootzeit. Anbieter müssen in der Konfiguration der Bootanzeige zwischenspeichern und beim nächsten Neustart in dieser Konfiguration starten. Wenn das Gerät in dieser Konfiguration nicht starten kann, muss der Anbieter eine Konfiguration finden, die der Auflösung und Bildwiederholrate dieser Konfiguration entspricht. Wenn keine solche Konfiguration vorhanden ist, sollte der Anbieter seine bevorzugte Displaykonfiguration verwenden.

    • Über clearBootDisplayConfig werden die Anbieter vom Framework aufgefordert, die Bootanzeigekonfiguration zu löschen und beim nächsten Neustart mit der bevorzugten Anzeigekonfiguration zu starten.

    • Über getPreferredBootDisplayConfig fragt das Framework den bevorzugten Bootmodus des Anbieters ab.

    Wenn die Konfiguration des Boot-Displays nicht unterstützt wird, geben diese Methoden den Wert UNSUPPORTED zurück.

  • Es wurden neue APIs hinzugefügt, um den Inaktivitätstimer des Displays zu steuern.

    • Mit DISPLAY_IDLE_TIMER können Anbieter angeben, dass für diese Anzeige ein Inaktivitätstimer vom Anbieter implementiert wird. Bei Inaktivität ändert diese Funktion die Aktualisierungsrate auf eine niedrigere Einstellung, um Energie zu sparen. Die Plattform verwendet setIdleTimerEnabled, um das Zeitlimit des Timers zu steuern und in einigen Fällen zu deaktivieren, damit bei Inaktivität keine unerwünschte Aktualisierung der Aktualisierungsrate aktiviert wird.

    • Mit dem IComposerCallback.onVsyncIdle-Callback wird der Plattform mitgeteilt, dass die Anzeige inaktiv ist und sich der vsync-Ablauf geändert hat. Die Plattform reagiert auf diesen Callback, indem sie ihr vsync-Modell zurücksetzt. Er erzwingt eine Neusynchronisierung von vsync mit dem nächsten Frame und lernt den neuen vsync-Ablauf.

Implementierung

Anbieter müssen die AIDL HAL für Android 13 nicht implementieren. Wir empfehlen jedoch, die HAL des AIDL-Kompilers anstelle der HIDL-Version zu implementieren, um die neuen Funktionen und APIs zu nutzen.

In Android-Emulatoren ist eine Referenzimplementierung für die AIDL HWC HAL implementiert.

Testen

Führen Sie VtsHalGraphicsComposer3_TargetTest aus, um die Implementierung zu testen.