AIDL für Hardware Composer HAL

Ab Android 13 wird die Hardware Composer (HWC) HAL in AIDL definiert und die HIDL-Versionen von android.hardware.graphics.composer@2.1 bis android.hardware.graphics.composer@2.4 sind eingestellt.

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

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

Unterschiede zwischen AIDL- und HIDL-HALs

Die neue AIDL-Composer-HAL mit dem Namen android.hardware.graphics.composer3 ist in IComposer.aidl definiert. Es wird eine API ähnlich dem HIDL-HAL android.hardware.graphics.composer@2.4 mit den folgenden Änderungen bereitgestellt:

  • Entfernung der Fast Message Queue (FMQ) zugunsten von parcelable-Befehlen.

    Die AIDL-HAL definiert die Befehlsschnittstelle basierend auf stark typisierten Parcelable-Typen im Gegensatz zu den serialisierten Befehlen über FMQ in HIDL. Dadurch wird eine stabile Schnittstelle für Befehle und eine besser lesbare Definition der Interpretation der Befehlspayload bereitgestellt.

    Die Methode executeCommands wird in IComposerClient.aidl so definiert:

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

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

  • Entfernung von IComposerClient.getClientTargetSupport, da es keine aktiven Clients für diese Methode gibt.

  • Darstellung von Farben als Gleitkommazahlen anstelle von Byte, um besser mit dem oberen Grafik-Stack in Android übereinzustimmen, wie in ASurfaceTransaction_setColor definiert.

  • Es wurden neue Felder zum Steuern von HDR-Inhalten hinzugefügt.

    In der AIDL-HAL unterstützen gemischte SDR/HDR-Layer-Stacks das nahtlose Dimmen von SDR-Layern, wenn gleichzeitig ein HDR-Layer auf dem Bildschirm angezeigt wird.

    Mit dem Feld brightness in LayerCommand kann SurfaceFlinger eine Helligkeit pro Ebene angeben, sodass der HWC den Inhalt der Ebene im linearen Lichtraum und nicht im Gammarum dimmt.

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

    Mit dem Feld dimmingStage kann der HWC konfigurieren, wann RenderEngine Inhalte dimmen soll. So können anbieterspezifische ColorModes, die möglicherweise lieber im Gammabereich gedimmt werden, anbieterspezifische Kontrastverbesserungen in ihren Farb-Pipelines zulassen.

  • Hinzufügen eines neuen Kompositionstyps DISPLAY_DECORATION in Composition.aidl für Bildschirmdekorationen.

    Einige Geräte haben eine spezielle Hardware, um das Zeichnen der Alphamaskierung zu optimieren, die abgerundete Ecken und Ausschnitte auf Displays glättet. Geräte mit dieser Hardware müssen IComposerClient.getDisplayDecorationSupport implementieren, um eine DisplayDecorationSupport-Struktur wie in der neuen DisplayDecorationSupport.aidl definiert zurückzugeben. Diese Struktur beschreibt die vom Gerät benötigten Enums PixelFormat und AlphaInterpretation. Nach dieser Implementierung kennzeichnet die System-UI die Alphamaskenebene als DISPLAY_DECORATION, einen neuen Kompositionstyp, der die dedizierte Hardware nutzt.

  • Das Feld expectedPresentTime wurde DisplayCommand.aidl hinzugefügt.

    Über das Feld expectedPresentTime kann SurfaceFlinger die erwartete Präsentationszeit festlegen, zu der die aktuellen Inhalte auf dem Bildschirm angezeigt werden müssen. Mit dieser Funktion sendet SurfaceFlinger einen Present-Befehl vorab an die Implementierung, sodass mehr Kompositionsarbeit in einer Pipeline ausgeführt werden kann.

  • Es wurden neue APIs hinzugefügt, mit denen die Konfiguration der Boot-Anzeige gesteuert werden kann.

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

    • Mit setBootDisplayConfig informiert das Framework Anbieter über die Konfiguration der Bootzeitanzeige. Anbieter müssen die Boot-Display-Konfiguration im Cache speichern und beim nächsten Neustart in dieser Konfiguration booten. Wenn das Gerät in dieser Konfiguration nicht gestartet werden 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.

    • Mit clearBootDisplayConfig informiert das Framework die Anbieter, die Boot-Display-Konfiguration zu löschen und beim nächsten Neustart in ihrer bevorzugten Display-Konfiguration zu booten.

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

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

  • Es wurden neue APIs hinzugefügt, mit denen der Inaktivitätstimer für das Display gesteuert werden kann.

    • Mit DISPLAY_IDLE_TIMER können Anbieter angeben, dass für diese Anzeige ein Inaktivitätstimer implementiert wird. Im Leerlauf wird die Aktualisierungsrate auf einen niedrigeren Wert geändert, um Strom zu sparen. Die Plattform verwendet setIdleTimerEnabled, um das Zeitlimit des Timers zu steuern und ihn in einigen Fällen zu deaktivieren, um unerwünschte Änderungen der Aktualisierungsrate im Leerlauf zu verhindern.

    • Durch die Verwendung des IComposerCallback.onVsyncIdle-Callbacks wird der Plattform mitgeteilt, dass das Display im Leerlauf ist und sich die vsync-Cadence geändert hat. Die Plattform reagiert auf diesen Callback, indem sie ihr vsync-Modell zurücksetzt. Dadurch wird im nächsten Frame eine vsync-Resynchronisierung erzwungen und die neue vsync-Kadenz wird gelernt.

Implementierung

Anbieter müssen die AIDL-HAL für Android 13 nicht implementieren. Es wird jedoch empfohlen, das AIDL-Composer-HAL anstelle der HIDL-Version zu implementieren, um die neuen Funktionen und APIs zu nutzen.

Eine Referenzimplementierung für das AIDL-HWC-HAL ist in Android-Emulatoren implementiert.

Testen

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