AIDL dla interfejsu HAL usługi Hardware Composer

Od Androida 13 interfejs HAL kompozytora sprzętowego (HWC) jest zdefiniowany w języku AIDL, a wersje HIDL z zakresu od android.hardware.graphics.composer@2.1 do android.hardware.graphics.composer@2.4 są wycofane.

Na tej stronie opisujemy różnice między interfejsem HAL AIDL a interfejsem HAL HIDL dla HWC oraz implementację i testowanie interfejsu HAL AIDL.

Ze względu na zalety, jakie oferuje AIDL, zachęcamy dostawców do wdrażania HAL kompozytora AIDL od Androida 13 zamiast wersji HIDL. Więcej informacji znajdziesz w sekcji Wdrażanie.

Różnice między interfejsami HAL AIDL i HIDL

Nowy interfejs HAL kompozytora AIDL o nazwie android.hardware.graphics.composer3 jest zdefiniowany w pliku IComposer.aidl. Udostępnia interfejs API podobny do HIDL HAL android.hardware.graphics.composer@2.4 z tymi zmianami:

  • Usunięcie szybkiej kolejki wiadomości (FMQ) na rzecz poleceń z możliwością przekazywania.

    AIDL HAL definiuje interfejs poleceń na podstawie typów z silnym typowaniem, które można przekazywać między procesami, w przeciwieństwie do serializowanych poleceń w HIDL za pomocą FMQ. Zapewnia to stabilny interfejs poleceń i czytelniejszą definicję sposobu interpretacji ładunku polecenia.

    Metoda executeCommands jest zdefiniowana w IComposerClient.aidl jako

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

    gdzie każde polecenie jest silnie typizowanym typem możliwym do przekazania w pakiecie, zdefiniowanym w pliku DisplayCommand.aidl. Odpowiedzi na polecenia są silnie typowanymi obiektami Parcelable zdefiniowanymi w pliku CommandResultPayload.aidl.

  • Usunięcie IComposerClient.getClientTargetSupport, ponieważ nie ma aktywnych klientów korzystających z tej metody.

  • Reprezentacja kolorów jako liczb zmiennoprzecinkowych zamiast bajtów, aby lepiej dopasować się do górnej warstwy graficznej w Androidzie zgodnie z definicją w ASurfaceTransaction_setColor.

  • Dodanie nowych pól do sterowania treściami HDR.

    W AIDL HAL mieszane stosy warstw SDR/HDR obsługują płynne przyciemnianie warstw SDR, gdy na ekranie jednocześnie znajduje się warstwa HDR.

    Pole brightness w LayerCommand umożliwia usłudze SurfaceFlinger określenie jasności poszczególnych warstw, dzięki czemu HWC przyciemnia zawartość warstwy w liniowej przestrzeni barw, a nie w przestrzeni gamma.

    Pole brightness w ClientTargetPropertyWithBrightness umożliwia HWC określenie przestrzeni jasności dla kompozycji klienta i instrukcji RenderEngine dotyczących przyciemniania warstw SDR w kompozycji klienta.

    Pole dimmingStage umożliwia HWC skonfigurowanie, kiedy RenderEngine ma przyciemniać treści. Umożliwia to dostosowanie do zdefiniowanych przez dostawcę wartości ColorModes, które mogą preferować przyciemnianie w przestrzeni gamma, aby umożliwić zdefiniowane przez dostawcę ulepszenia kontrastu w ich potokach kolorów.

  • Dodanie nowego typu kompozycji DISPLAY_DECORATION w Composition.aidl do dekoracji ekranu.

    Niektóre urządzenia mają specjalne komponenty, które optymalizują rysowanie maski alfa wygładzającej zaokrąglone rogi i wycięcia na wyświetlaczach. Urządzenia z takim sprzętem muszą implementować IComposerClient.getDisplayDecorationSupport, aby zwracać strukturę DisplayDecorationSupport zdefiniowaną w nowym DisplayDecorationSupport.aidl. Ta struktura opisuje wyliczenia PixelFormat i AlphaInterpretation wymagane przez urządzenie. Po wdrożeniu tej funkcji interfejs systemu oznaczy warstwę maski alfa jako DISPLAY_DECORATION, czyli nowy typ kompozycji, który wykorzystuje dedykowany sprzęt.

  • Dodanie nowego pola expectedPresentTime do DisplayCommand.aidl.

    Pole expectedPresentTime umożliwia usłudze SurfaceFlinger ustawienie oczekiwanego czasu wyświetlania na moment, w którym bieżące treści muszą być wyświetlane na ekranie. Dzięki tej funkcji SurfaceFlinger wysyła polecenie prezentacji do implementacji z wyprzedzeniem, co pozwala na bardziej potokowe wykonywanie pracy związanej z kompozycją.

  • Dodanie nowych interfejsów API do kontrolowania konfiguracji wyświetlania podczas uruchamiania.

    Za pomocą parametru BOOT_DISPLAY_CONFIG dostawcy mogą określić, że konfiguracja wyświetlacza rozruchowego jest obsługiwana. Metody setBootDisplayConfig, clearBootDisplayConfig i getPreferredBootDisplayConfig używają BOOT_DISPLAY_CONFIG w ten sposób:

    • Za pomocą interfejsu setBootDisplayConfig platforma informuje dostawców o konfiguracji wyświetlania czasu rozruchu. Dostawcy muszą przechowywać w pamięci podręcznej konfigurację wyświetlania podczas uruchamiania i uruchamiać się w tej konfiguracji przy następnym ponownym uruchomieniu. Jeśli urządzenie nie może się uruchomić w tej konfiguracji, dostawca musi znaleźć konfigurację, która pasuje do rozdzielczości i częstotliwości odświeżania tej konfiguracji. Jeśli taka konfiguracja nie istnieje, dostawca powinien użyć preferowanej konfiguracji wyświetlania.

    • Korzystając z clearBootDisplayConfig, platforma informuje dostawców, aby wyczyścili konfigurację wyświetlacza rozruchowego i przy następnym ponownym uruchomieniu włączyli preferowaną konfigurację wyświetlacza.

    • Korzystając z getPreferredBootDisplayConfig, platforma wysyła zapytanie o preferowany tryb uruchamiania dostawcy.

    Jeśli konfiguracja wyświetlacza rozruchowego nie jest obsługiwana, te metody zwracają wartość UNSUPPORTED.

  • Dodanie nowych interfejsów API do sterowania licznikiem czasu bezczynności wyświetlacza.

    • Za pomocą parametru DISPLAY_IDLE_TIMER dostawcy mogą określić, że w przypadku tego wyświetlenia dostawca implementuje licznik czasu bezczynności. Gdy urządzenie jest nieaktywne, ta funkcja zmienia częstotliwość odświeżania na niższą, aby oszczędzać energię. Platforma używa setIdleTimerEnabled do kontrolowania limitu czasu timera, a w niektórych przypadkach do jego wyłączania, aby zapobiec niepożądanym zmianom częstotliwości odświeżania w stanie bezczynności.

    • Użycie wywołania zwrotnego IComposerCallback.onVsyncIdle informuje platformę, że wyświetlacz jest nieaktywny, a częstotliwość vsync została zmieniona. Platforma odpowiada na to wywołanie zwrotne, resetując model vsync. Wymusza vsync ponowną synchronizację w następnej klatce i uczy się nowej vsync kadencji.

Implementacja

W przypadku Androida 13 dostawcy nie muszą wdrażać interfejsu AIDL HAL. Zachęcamy jednak do wdrożenia kompozytora HAL AIDL zamiast wersji HIDL, aby korzystać z nowych funkcji i interfejsów API.

Implementacja referencyjna interfejsu HAL HWC AIDL jest zaimplementowana w emulatorach Androida.

Testowanie

Aby przetestować implementację, uruchom VtsHalGraphicsComposer3_TargetTest.