AIDL для HAL аппаратного композитора

Начиная с Android 13, HAL Hardware Composer (HWC) определяется в AIDL. Версии HIDL от android.hardware.graphics.composer@2.1 до android.hardware.graphics.composer@2.4 больше не поддерживаются.

На этой странице описаны различия между HAL-уровнями AIDL и HIDL для HWC, а также рассказывается, как реализовать и протестировать HAL-уровень AIDL.

Поскольку AIDL имеет преимущества, поставщики могут реализовать HAL композитора AIDL, начиная с Android 13, вместо версии HIDL. Подробнее о реализации…

Различия между HAL AIDL и HIDL

Новый HAL-модуль Composer на основе AIDL, который называется android.hardware.graphics.composer3, определен в IComposer.aidl. Этот API похож на HIDL HAL android.hardware.graphics.composer@2.4, но имеет следующие отличия:

• Удаление очереди быстрых сообщений (FMQ) в пользу команд, которые можно передавать с помощью Parcelable.

  AIDL HAL определяет интерфейс команд на основе строго типизированных типов parcelable вместо сериализованных команд через FMQ в HIDL. Это обеспечивает стабильный интерфейс для команд и более понятное определение того, как система интерпретирует полезную нагрузку команды.

  Метод executeCommands 5 определен в файле IComposerClient.aidl:

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

  Каждая команда представляет собой строго типизированный объект Parcelable, определенный в файле DisplayCommand.aidl. Ответы на команды – это строго типизированные объекты Parcelable, определенные в CommandResultPayload.aidl.

• Удаление IComposerClient.getClientTargetSupport, так как этот метод не используется активными клиентами.

• Цвета представлены в виде чисел с плавающей запятой, а не байтов, чтобы соответствовать верхнему графическому стеку в Android, как определено в ASurfaceTransaction_setColor.

• Добавлены новые поля для управления HDR-контентом.

  В AIDL HAL смешанные стеки слоев SDR/HDR поддерживают плавное затемнение слоев SDR, когда на экране одновременно присутствует слой HDR.

  Поле brightness в LayerCommand позволяет SurfaceFlinger задавать яркость для каждого слоя. Это позволяет HWC затемнять контент слоя в линейном цветовом пространстве, а не в гамма-пространстве.

  Поле brightness в ClientTargetPropertyWithBrightness позволяет HWC указать пространство яркости для композиции клиента и сообщает RenderEngine, нужно ли затемнять слои SDR в композиции клиента.

  Поле dimmingStage позволяет HWC настраивать, когда RenderEngine затемняет контент. Это позволяет использовать определенные поставщиком ColorModes настройки, например затемнение в гамма-пространстве для улучшения контрастности в цветовых конвейерах.

• Добавлен тип композиции DISPLAY_DECORATION в Composition.aidl для элементов оформления экрана.

  На некоторых устройствах есть специальное оборудование, которое оптимизирует отрисовку альфа-маски, сглаживающей закругленные углы и вырезы на дисплеях. Устройства с таким оборудованием должны реализовывать IComposerClient.getDisplayDecorationSupport и возвращать структуру DisplayDecorationSupport, как описано в DisplayDecorationSupport.aidl. Эта структура описывает перечисления PixelFormat и AlphaInterpretation, необходимые для устройства. После этого системный интерфейс помечает слой альфа-маски как DISPLAY_DECORATION – тип композиции, который использует преимущества специального оборудования.

• Добавлено поле expectedPresentTime в DisplayCommand.aidl.

  Поле expectedPresentTime позволяет SurfaceFlinger задать ожидаемое время, когда текущий контент должен быть показан на экране. Благодаря этой функции SurfaceFlinger отправляет команду present в реализацию заранее, что позволяет ей конвейеризировать больше задач по композиции.

• Добавлены новые API для управления конфигурацией экрана загрузки.

  С помощью BOOT_DISPLAY_CONFIG поставщики могут указать, что конфигурация экрана загрузки поддерживается. Методы setBootDisplayConfig, clearBootDisplayConfig и getPreferredBootDisplayConfig используют BOOT_DISPLAY_CONFIG следующим образом:

  • С помощью setBootDisplayConfig платформа сообщает поставщикам о конфигурации экрана во время загрузки. Поставщики должны кэшировать конфигурацию загрузочного дисплея и использовать ее при следующей перезагрузке. Если устройство не может загрузиться с такими настройками, поставщик должен найти конфигурацию, которая соответствует разрешению и частоте обновления экрана. Если такой конфигурации нет, поставщик должен использовать предпочитаемую конфигурацию показа.

  • С помощью clearBootDisplayConfig фреймворк сообщает поставщикам, что нужно очистить конфигурацию дисплея при загрузке и загрузить предпочтительную конфигурацию дисплея во время следующей перезагрузки.

  • С помощью getPreferredBootDisplayConfig фреймворк запрашивает предпочтительный режим загрузки у поставщика.

  Если конфигурация экрана при загрузке не поддерживается, эти методы возвращают значение UNSUPPORTED.

• Добавлены новые API для управления таймером бездействия экрана:

  • С помощью DISPLAY_IDLE_TIMER поставщики могут указать, что таймер бездействия для этого показа реализован поставщиком. Когда устройство не используется, эта функция снижает частоту обновления экрана, чтобы экономить энергию. Платформа использует setIdleTimerEnabled для управления временем ожидания таймера, а в некоторых случаях – для его отключения, чтобы предотвратить нежелательное переключение частоты обновления в режиме ожидания.

  • Обратный вызов IComposerCallback.onVsyncIdle сообщает платформе, что экран неактивен и частота vsync изменилась. Платформа отвечает на этот обратный вызов, сбрасывая свою модель vsync. Он принудительно выполняет повторную синхронизацию vsync на следующем кадре и запоминает новый ритм vsync.

Реализация

Поставщики не обязаны реализовывать AIDL HAL для Android 13. Однако поставщикам рекомендуется реализовать HAL композитора AIDL вместо версии HIDL, чтобы использовать функции и API HAL композитора AIDL.

Эмуляторы Android включают референсную реализацию для AIDL HWC HAL.

Тестирование

Чтобы проверить реализацию, запустите команду VtsHalGraphicsComposer3_TargetTest.