AIDL für Hardware Composer HAL

Ab Android 13 ist der 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 veraltet.

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

Aufgrund der Vorteile , die AIDL bietet, werden Anbieter dazu ermutigt, 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

Der neue AIDL Composer HAL mit dem Namen android.hardware.graphics.composer3 ist in IComposer.aidl definiert. Es stellt eine API ähnlich der HIDL HAL android.hardware.graphics.composer@2.4 mit den folgenden Änderungen bereit:

  • Entfernung der Fast Message Queue (FMQ) zugunsten parzellierbarer Befehle.

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

    Die Methode executeCommands ist in IComposerClient.aidl definiert als

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

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

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

  • Darstellung von Farben als Floats anstelle von Bytes, um sie besser an den oberen Grafikstapel in Android anzupassen, wie in ASurfaceTransaction_setColor definiert.

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

    Im 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 in LayerCommand kann SurfaceFlinger eine Helligkeit pro Ebene festlegen, sodass der HWC den Inhalt der Ebene im linearen Lichtraum und nicht im Gammaraum dimmt.

    Mit dem brightness in ClientTargetPropertyWithBrightness kann das 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 die HWC konfigurieren, wann RenderEngine Inhalte dimmen soll. Dies berücksichtigt herstellerdefinierte ColorModes , die möglicherweise lieber im Gammaraum dimmen, um herstellerdefinierte Kontrastverbesserungen in ihren Farbpipelines zu ermöglichen.

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

    Einige Geräte verfügen über 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 zurückzugeben, wie im neuen DisplayDecorationSupport.aidl definiert. Diese Struktur beschreibt die vom Gerät benötigten PixelFormat und AlphaInterpretation Enumerationen. Bei dieser Implementierung markiert die System-Benutzeroberfläche die Alphamaskenebene als DISPLAY_DECORATION , einen neuen Kompositionstyp, der die Vorteile der dedizierten Hardware nutzt.

  • Hinzufügung eines neuen Felds expectedPresentTime zu DisplayCommand.aidl .

    Mit dem Feld expectedPresentTime kann SurfaceFlinger die erwartete aktuelle Zeit festlegen, zu der der aktuelle Inhalt auf dem Bildschirm angezeigt werden muss. Mit dieser Funktion sendet SurfaceFlinger vorab einen aktuellen Befehl an die Implementierung, sodass diese einen größeren Teil der Kompositionsarbeit weiterleiten kann.

  • Hinzufügung neuer APIs zur Steuerung der Boot-Anzeigekonfiguration.

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

    • Mit setBootDisplayConfig informiert das Framework Anbieter über die Konfiguration der Startzeitanzeige. Anbieter müssen die Startanzeigekonfiguration zwischenspeichern und beim nächsten Neustart in dieser Konfiguration starten. Wenn das Gerät mit 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, sollte der Anbieter seine bevorzugte Anzeigekonfiguration verwenden.

    • Mit clearBootDisplayConfig weist das Framework die Anbieter an, die Boot-Anzeigekonfiguration zu löschen und beim nächsten Neustart mit ihrer bevorzugten Anzeigekonfiguration zu booten.

    • Mithilfe von getPreferredBootDisplayConfig fragt das Framework den bevorzugten Startmodus des Anbieters ab.

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

  • Hinzufügung neuer APIs zur Steuerung des Anzeige-Leerlaufzeit-Timers.

    • Mithilfe von DISPLAY_IDLE_TIMER können Anbieter festlegen, dass der Anbieter für diese Anzeige einen Inaktivitäts-Timer implementiert. Im Ruhezustand ändert diese Funktion die Bildwiederholfrequenz auf eine niedrigere Einstellung, um Strom zu sparen. Die Plattform verwendet setIdleTimerEnabled , um das Timeout des Timers zu steuern und in einigen Fällen zu deaktivieren, um unerwünschte Aktualisierungsratenwechsel im Leerlauf zu verhindern.

    • Die Verwendung des IComposerCallback.onVsyncIdle Rückrufs zeigt der Plattform an, dass die Anzeige inaktiv ist und sich die vsync Taktfrequenz geändert hat. Die Plattform reagiert auf diesen Rückruf, indem sie ihr vsync Modell zurücksetzt. Es erzwingt eine erneute vsync Synchronisierung beim nächsten Frame und lernt die neue vsync Kadenz.

Implementierung

Anbieter sind nicht verpflichtet, die AIDL-HAL für Android 13 zu implementieren. Sie werden jedoch aufgefordert, die AIDL- Composer-HAL anstelle der HIDL-Version zu implementieren, um die neuen Funktionen und APIs zu nutzen.

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

Testen

Um Ihre Implementierung zu testen, führen Sie VtsHalGraphicsComposer3_TargetTest aus.