AIDL für Hardware Composer HAL

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

Auf dieser Seite werden die Unterschiede zwischen den AIDL- und HIDL-HALs für den HWC beschrieben. Außerdem wird erläutert, wie die AIDL-HAL implementiert und getestet wird.

Da AIDL Vorteile bietet, können Anbieter die AIDL-Composer-HAL ab Android 13 anstelle der HIDL-Version 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. Die API ähnelt der HIDL-HAL android.hardware.graphics.composer@2.4, enthält aber die folgenden Änderungen:

  • Die Fast Message Queue (FMQ) wurde zugunsten von parcelable-Befehlen entfernt.

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

    Die Methode executeCommands 5 ist in IComposerClient.aidl definiert:

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

    Jeder Befehl ist 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 keine aktiven Clients diese Methode verwenden.

  • Farben werden als Gleitkommazahlen anstelle von Byte dargestellt, um sie an den oberen Grafik-Stack in Android anzupassen, wie in ASurfaceTransaction_setColor definiert.

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

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

    Im Feld brightness in LayerCommand kann SurfaceFlinger eine Helligkeit pro Ebene angeben. Dadurch kann der HWC den Inhalt der Ebene im linearen Lichtraum anstelle des Gammaspace dimmen.

    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 dimmt. So wird ColorModes des Anbieters berücksichtigt, das möglicherweise lieber im Gammabereich gedimmt wird, um anbieterdefinierte Kontrasterweiterungen in den Farb-Pipelines zu ermöglichen.

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

    Einige Geräte haben eine spezielle Hardware, um das Zeichnen der Alphamaske zu optimieren, die abgerundete Ecken und Ausschnitte auf Displays glättet. Auf Geräten mit dieser Hardware muss IComposerClient.getDisplayDecorationSupport implementiert und eine DisplayDecorationSupport-Struktur wie in DisplayDecorationSupport.aidl definiert zurückgegeben werden. Diese Struktur beschreibt die Enums PixelFormat und AlphaInterpretation, die für das Gerät erforderlich sind. Nach dieser Implementierung kennzeichnet die System-UI die Alphamaskenebene als DISPLAY_DECORATION, einen 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 vorzeitig an die Implementierung, wodurch mehr Kompositionsarbeit in die Pipeline aufgenommen 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 Konfiguration des Bootdisplays unterstützt wird. Die Methoden setBootDisplayConfig, clearBootDisplayConfig und getPreferredBootDisplayConfig verwenden BOOT_DISPLAY_CONFIG so:

    • Mit setBootDisplayConfig informiert das Framework Anbieter über die Konfiguration der Anzeige während der Bootzeit. 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, muss der Anbieter seine bevorzugte Displaykonfiguration verwenden.

    • Mit clearBootDisplayConfig werden die Anbieter vom Framework aufgefordert, die Boot-Displaykonfiguration zu löschen und beim nächsten Neustart mit ihrer bevorzugten Displaykonfiguration 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.

  • Neue APIs zum Steuern des Inaktivitätstimers für das Display:

    • Mit DISPLAY_IDLE_TIMER können Anbieter angeben, dass für dieses Display 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.

    • Mit dem IComposerCallback.onVsyncIdle-Callback wird der Plattform mitgeteilt, dass das Display im Leerlauf ist und sich die vsync-Kadenz 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. Wir empfehlen Anbietern jedoch, die AIDL-Composer-HAL anstelle der HIDL-Version zu implementieren, um die Funktionen und APIs der AIDL-Composer-HAL zu nutzen.

Android-Emulatoren enthalten eine Referenzimplementierung für das AIDL-HWC-HAL.

Testen

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