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 der AIDL- und der HIDL-HAL für die HWC sowie die Implementierung und Prüfung der AIDL-HAL beschrieben.

Aufgrund der Vorteile von AIDL empfehlen wir Anbietern, ab Android 13 die 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-Kompilator, android.hardware.graphics.composer3, ist in IComposer.aidl definiert. Sie stellt eine API bereit, die der HIDL HALandroid.hardware.graphics.composer@2.4 ähnelt, mit den folgenden Änderungen:

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

    Die AIDL HAL definiert die Befehlsschnittstelle basierend auf stark typisierten, parzellierbaren Typen im Gegensatz zu den serialisierten Befehlen über FMQ in HIDL. Dies bietet eine stabile Schnittstelle für Befehle und eine übersichtliche Definition der Interpretation der Befehlsnutzlast.

    Die Methode executeCommands ist in IComposerClient.aidl so definiert:

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

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

  • IComposerClient.getClientTargetSupport wurde entfernt, da es für diese Methode keine aktiven Kunden gibt.

  • Darstellung von Farben als Floats anstelle von Bytes, um besser mit dem oberen Grafikstack in Android übereinzustimmen, wie in ASurfaceTransaction_setColor definiert.

  • Es wurden neue Felder für die 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 die 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 der HWC konfigurieren, wann RenderEngine Inhalte dimmen soll. Dies ermöglicht die Verwendung von vom Anbieter definierten ColorModes, die im Gammaraum gedimmt werden können, um vom Anbieter definierte 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 dieser Hardware müssen IComposerClient.getDisplayDecorationSupport implementieren, um eine DisplayDecorationSupport-Struktur gemäß der neuen DisplayDecorationSupport.aidl zurückzugeben. In dieser Struktur werden die vom Gerät benötigten PixelFormat- und AlphaInterpretation-Enume beschrieben. Bei dieser Implementierung kennzeichnet die System-UI die Alphamaskenebene als DISPLAY_DECORATION, einen neuen Kompositiontyp, der die spezielle Hardware nutzt.

  • DisplayCommand.aidl wurde ein neues expectedPresentTime-Feld hinzugefügt.

    Mit dem Feld expectedPresentTime kann SurfaceFlinger die voraussichtliche aktuelle Zeit festlegen, zu der die aktuellen Inhalte auf dem Bildschirm angezeigt werden müssen. Mit dieser Funktion sendet SurfaceFlinger einen Befehl zum Präsentieren vorab an die Implementierung, sodass mehr der Zusammensetzungsarbeit in die Pipeline aufgenommen werden kann.

  • Es wurden neue APIs hinzugefügt, um die Konfiguration des Bootbildschirms zu steuern.

    Mit BOOT_DISPLAY_CONFIG können Anbieter angeben, dass die Konfiguration des Bootbildschirms unterstützt wird. Bei den Methoden setBootDisplayConfig, clearBootDisplayConfig und getPreferredBootDisplayConfig wird BOOT_DISPLAY_CONFIG folgendermaßen verwendet:

    • Über setBootDisplayConfig informiert das Framework die Anbieter über die Konfiguration der Anzeige zur Bootzeit. Anbieter müssen die Konfiguration des Boot-Displays im Cache speichern und beim nächsten Neustart mit 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 Konfigurationseinstellung für das Boot-Display 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. Im Inaktivitätsmodus wird die Bildwiederholrate auf eine niedrigere Einstellung geändert, um den Stromverbrauch zu senken. Die Plattform verwendet setIdleTimerEnabled, um das Zeitlimit des Timers zu steuern und in einigen Fällen zu deaktivieren, um unerwünschte Wechsel der Bildwiederholrate im Inaktivitätsmodus zu verhindern.

    • Mit dem Callback IComposerCallback.onVsyncIdle wird der Plattform mitgeteilt, dass das Display inaktiv ist und sich die vsync-Taktfrequenz geändert hat. Die Plattform antwortet auf diesen Rückruf, indem sie das vsync-Modell zurücksetzt. Es erzwingt eine vsync-Synchronisierung im nächsten Frame und lernt die neue vsync-Taktfrequenz.

Implementierung

Anbieter müssen die AIDL HAL für Android 13 nicht implementieren. Wir empfehlen jedoch, die AIDL-Composer HAL 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 Ihre Implementierung zu testen.