Начиная с Android 13, HAL Hardware Composer (HWC) определен в AIDL , а версии HIDL от android.hardware.graphics.composer@2.1
до android.hardware.graphics.composer@2.4
устарели.
На этой странице описываются различия между AIDL и HIDL HAL для HWC, а также реализация и тестирование AIDL HAL.
Учитывая преимущества AIDL, поставщикам рекомендуется использовать HAL-композитор AIDL , начиная с Android 13, вместо версии HIDL. Подробнее см. в разделе «Внедрение» .
Различия между HAL AIDL и HIDL
Новый HAL-компонент AIDL, названный android.hardware.graphics.composer3
, определён в IComposer.aidl
. Он предоставляет API, аналогичный HAL-компоненту HIDL android.hardware.graphics.composer@2.4
, со следующими изменениями:
Удаление быстрой очереди сообщений (FMQ) в пользу пакетируемых команд.
В AIDL HAL интерфейс команд определяется на основе строго типизированных парцеллятивных типов, в отличие от сериализованных команд через FMQ в HIDL. Это обеспечивает стабильный интерфейс для команд и более понятное описание интерпретации полезной нагрузки команды.
Метод
executeCommands
определен в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 заранее отправляет команду «текущее время» реализации, позволяя ей выполнять большую часть работы по компоновке.Добавление новых 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. Однако им рекомендуется внедрять AIDL Composer HAL вместо версии HIDL, чтобы использовать новые функции и API.
Эталонная реализация AIDL HWC HAL реализована в эмуляторах Android.
Тестирование
Чтобы протестировать реализацию, запустите VtsHalGraphicsComposer3_TargetTest
.