AIDL für Hardware Composer HAL

Ab Android 13 ist die Hardware Composer (HWC) HAL in AIDLdefiniert. 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 die HWC beschrieben und es wird erläutert, wie die AIDL-HAL implementiert und getestet wird.

Da AIDL Vorteile bietet, können Anbieter ab Android 13 die AIDL Composer-HAL 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:

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

    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 Befehlslast durch das System bereitgestellt.

    Die executeCommands 5 Methode 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 diese Methode von keinen aktiven Clients verwendet wird.

  • Darstellung von Farben als Gleitkommazahlen anstelle von Byte, um sie an den oberen Grafikstack in Android anzugleichen, wie in ASurfaceTransaction_setColordefiniert.

  • Hinzufügen neuer Felder zur Steuerung von HDR-Inhalten.

    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 brightness Feld in LayerCommand kann SurfaceFlinger eine Helligkeit pro Layer angeben. Dadurch kann die HWC den Inhalt des Layers im linearen Lichtraum anstelle des Gamma-Raums dimmen.

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

    Das dimmingStage Feld lässt die HWC konfigurieren, wann RenderEngine Inhalte dimmt. Dies berücksichtigt anbieterspezifische ColorModes, bei denen das Dimmen im Gamma-Raum bevorzugt wird, um anbieterspezifische Kontrasterweiterungen in ihren Farbpipelines zu ermöglichen.

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

    Einige Geräte haben spezielle Hardware, um das Zeichnen der Alpha-Maske zu optimieren, die abgerundete Ecken und Ausschnitte auf Displays glättet. Geräte mit dieser Hardware müssen IComposerClient.getDisplayDecorationSupport implementieren und eine DisplayDecorationSupport Struktur zurückgeben, wie in DisplayDecorationSupport.aidl definiert. Diese Struktur beschreibt die PixelFormat- und AlphaInterpretation -Enums, die vom Gerät benötigt werden. Nach dieser Implementierung markiert die System-UI den Alpha-Masken-Layer als DISPLAY_DECORATION, einen Komposition styp, der die spezielle Hardware nutzt.

  • Hinzufügen eines expectedPresentTime Felds zu DisplayCommand.aidl.

    Mit dem Feld expectedPresentTime kann SurfaceFlinger die erwartete Präsentationszeit festlegen, zu der der aktuelle Inhalt auf dem Bildschirm angezeigt werden muss. Mit dieser Funktion sendet SurfaceFlinger einen Präsentationsbefehl vorzeitig an die Implementierung, wodurch mehr Kompositionsarbeit in die Pipeline aufgenommen werden kann.

  • Hinzufügen neuer APIs zur Steuerung der Boot-Display-Konfiguration.

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

    • Mit setBootDisplayConfig informiert das Framework Anbieter über die Display-Konfiguration zur 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 booten kann, muss der Anbieter eine Konfiguration finden, die der Auflösung und Aktualisierungsrate dieser Konfiguration entspricht. Wenn keine solche Konfiguration vorhanden ist, muss der Anbieter seine bevorzugte Display-Konfiguration verwenden.

    • Mit clearBootDisplayConfig weist das Framework die Anbieter an , 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 Boot-Display-Konfiguration nicht unterstützt wird, geben diese Methoden den Wert UNSUPPORTED zurück.

  • Hinzufügen neuer APIs zur Steuerung des Timers für die Inaktivität des Displays:

    • Mit DISPLAY_IDLE_TIMER können Anbieter angeben, dass ein Inaktivitätstimer für dieses Display vom Anbieter implementiert wird. Im Leerlauf ä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 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 sich das Display im Leerlauf befindet und sich die vsync Kadenz geändert hat. Die Plattform reagiert auf diesen Callback, indem sie ihr vsync-Modell zurücksetzt. Sie erzwingt eine vsync-Neusynchronisierung für den nächsten Frame und lernt die neue vsync-Kadenz.

Implementierung

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

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

Test

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