A partir de Android 13, la HAL de Hardware Composer (HWC) se define en AIDL. Las versiones de HIDL que van de android.hardware.graphics.composer@2.1
a android.hardware.graphics.composer@2.4
dejaron de estar disponibles.
En esta página, se describen las diferencias entre las HAL de AIDL y HIDL para el HWC, y cómo implementar y probar la HAL de AIDL.
Dado que AIDL ofrece ventajas, los proveedores pueden implementar la HAL de compositor AIDL a partir de Android 13 en lugar de la versión HIDL. Para obtener más información, consulta la sección Implementación.
Diferencias entre los HAL de AIDL y HIDL
La nueva HAL de compositor de AIDL, llamada android.hardware.graphics.composer3
, se define en IComposer.aidl
. La API es similar al HAL de HIDL android.hardware.graphics.composer@2.4
, pero incluye los siguientes cambios:
Se quitó la cola de mensajes rápidos (FMQ) en favor de los comandos parcelables.
El HAL de AIDL define la interfaz de comandos en función de tipos parcelables con escritura segura en lugar de los comandos serializados a través de FMQ en HIDL. Esto proporciona una interfaz estable para los comandos y una definición más legible de cómo el sistema interpreta la carga útil del comando.
El método
executeCommands
5 se define enIComposerClient.aidl
:CommandResultPayload[] executeCommands(in DisplayCommand[] commands);
Cada comando es un tipo parcelable con escritura segura definido en
DisplayCommand.aidl
. Las respuestas de comandos son objetos Parcelables con escritura sólida definidos enCommandResultPayload.aidl
.Se quitó
IComposerClient.getClientTargetSupport
porque ningún cliente activo usa este método.Representación de colores como números de punto flotante en lugar de bytes para alinearse con la pila de gráficos superior en Android, según lo define
ASurfaceTransaction_setColor
.Se agregaron campos nuevos para controlar el contenido HDR.
En el HAL de AIDL, las pilas de capas mixtas de SDR/HDR admiten la atenuación perfecta de las capas de SDR cuando una capa de HDR está en la pantalla al mismo tiempo.
El campo
brightness
enLayerCommand
permite que SurfaceFlinger especifique un brillo por capa. Esto permite que el HWC atenúe el contenido de la capa en el espacio de luz lineal en lugar del espacio gamma.El campo
brightness
enClientTargetPropertyWithBrightness
permite que el HWC especifique el espacio de brillo para la composición del cliente y le indica aRenderEngine
si debe atenuar las capas SDR en la composición del cliente.El campo
dimmingStage
permite que el HWC configure cuándoRenderEngine
atenúa el contenido. Esto admite elColorModes
definido por el proveedor que podría preferir atenuar en el espacio gamma para habilitar las mejoras de contraste definidas por el proveedor en sus canalizaciones de color.Se agregó un tipo de composición,
DISPLAY_DECORATION
, enComposition.aidl
para las decoraciones de pantalla.Algunos dispositivos tienen hardware dedicado para optimizar el dibujo de la máscara alfa que suaviza las esquinas redondeadas y los cortes en las pantallas. Los dispositivos con este hardware deben implementar
IComposerClient.getDisplayDecorationSupport
y devolver una estructuraDisplayDecorationSupport
como se define enDisplayDecorationSupport.aidl
. Esta estructura describe los enumsPixelFormat
yAlphaInterpretation
que requiere el dispositivo. Después de esta implementación, la IU del sistema marca la capa de máscara alfa comoDISPLAY_DECORATION
, un tipo de composición que aprovecha el hardware dedicado.Se agregó un campo
expectedPresentTime
aDisplayCommand.aidl
.El campo
expectedPresentTime
permite que SurfaceFlinger establezca la hora de presentación esperada para cuando se debe mostrar el contenido actual en la pantalla. Con esta función, SurfaceFlinger envía un comando de presentación a la implementación con anticipación, lo que le permite canalizar más trabajo de composición.Se agregaron nuevas APIs para controlar la configuración de la pantalla de inicio.
Con
BOOT_DISPLAY_CONFIG
, los proveedores pueden especificar que se admite la configuración de pantalla de arranque. Los métodossetBootDisplayConfig
,clearBootDisplayConfig
ygetPreferredBootDisplayConfig
usanBOOT_DISPLAY_CONFIG
de la siguiente manera:Con
setBootDisplayConfig
, el framework informa a los proveedores sobre la configuración de pantalla de tiempo de arranque. Los proveedores deben almacenar en caché la configuración de la pantalla de arranque y arrancar en esta configuración en el próximo reinicio. Si el dispositivo no puede arrancar con esta configuración, el proveedor debe encontrar una configuración que coincida con la resolución y la frecuencia de actualización de esta configuración. Si no existe tal configuración, el proveedor debe usar su configuración de pantalla preferida.Con
clearBootDisplayConfig
, el framework informa a los proveedores que deben borrar la configuración de pantalla de inicio y arrancar con su configuración de pantalla preferida durante el próximo reinicio.Con
getPreferredBootDisplayConfig
, el framework consulta el modo de arranque preferido del proveedor.
Cuando no se admite la configuración de pantalla de arranque, estos métodos devuelven un valor de
UNSUPPORTED
.Se agregaron nuevas APIs para controlar el temporizador de inactividad de la pantalla:
Con
DISPLAY_IDLE_TIMER
, los proveedores pueden especificar que implementaron un temporizador de inactividad para esta pantalla. Cuando está inactiva, esta capacidad cambia la frecuencia de actualización a un parámetro de configuración más bajo para ahorrar energía. La plataforma usasetIdleTimerEnabled
para controlar el tiempo de espera del temporizador y, en algunos casos, para inhabilitarlo y evitar cambios no deseados en la frecuencia de actualización cuando está inactivo.Usar la devolución de llamada
IComposerCallback.onVsyncIdle
indica a la plataforma que la pantalla está inactiva y que cambió la cadencia devsync
. La plataforma responde a esta devolución de llamada restableciendo su modelo devsync
. Fuerza una resincronización devsync
en el siguiente fotograma y aprende la nueva cadencia devsync
.
Implementación
Los proveedores no tienen la obligación de implementar la HAL del AIDL para Android 13. Sin embargo, se recomienda a los proveedores que implementen la HAL de compositor de AIDL en lugar de la versión de HIDL para usar la funcionalidad y las APIs de la HAL de compositor de AIDL.
Los emuladores de Android incluyen una implementación de referencia para la HAL de HWC del AIDL.
Prueba
Para probar tu implementación, ejecuta VtsHalGraphicsComposer3_TargetTest
.