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