A partir de Android 13, la HAL del compositor de hardware (HWC) se define en AIDL y las versiones de HIDL que van desde android.hardware.graphics.composer@2.1
hasta android.hardware.graphics.composer@2.4
están obsoletas.
Esta página describe las diferencias entre el AIDL y el HIDL HAL para el HWC y la implementación y prueba del AIDL HAL.
Debido a las ventajas que ofrece AIDL, se alienta a los proveedores a implementar el compositor de AIDL HAL a partir de Android 13 en lugar de la versión HIDL. Consulte la sección Implementación para obtener más información.
Diferencias entre HAL AIDL e HIDL
El nuevo compositor HAL de AIDL, denominado android.hardware.graphics.composer3
, se define en IComposer.aidl
. Expone una API similar a HIDL HAL android.hardware.graphics.composer@2.4
con los siguientes cambios:
Eliminación de Fast Message Queue (FMQ) en favor de comandos encomendables.
AIDL HAL define la interfaz de comandos basada en tipos de paquetes fuertemente tipados en oposición a los comandos serializados sobre FMQ en HIDL. Esto proporciona una interfaz estable para los comandos y una definición más legible de cómo se interpreta la carga del comando.
El método
executeCommands
se define enIComposerClient.aidl
comoCommandResultPayload[] executeCommands(in DisplayCommand[] commands);
donde cada comando es un tipo parcelable fuertemente tipado definido en
DisplayCommand.aidl
. Las respuestas de los comandos son parcelables fuertemente tipados definidos enCommandResultPayload.aidl
.Eliminación de
IComposerClient.getClientTargetSupport
ya que no hay clientes activos para este método.Representación de colores como flotadores en lugar de bytes para alinearse mejor con la pila de gráficos superior en Android como se define en
ASurfaceTransaction_setColor
.Adición de nuevos campos para controlar contenido HDR.
En AIDL HAL, las pilas de capas SDR/HDR mixtas admiten la atenuación continua de las capas SDR cuando una capa HDR está simultáneamente en la pantalla.
El campo
brightness
enLayerCommand
permite que SurfaceFlinger especifique un brillo por capa, de modo que el HWC atenúa el contenido de la capa en un espacio de luz lineal, a diferencia del espacio gamma.El campo
brightness
enClientTargetPropertyWithBrightness
le permite al HWC especificar el espacio de brillo para la composición del cliente e indicarRenderEngine
si debe atenuar las capas SDR en la composición del cliente.El campo
dimmingStage
permite que HWC configure cuándoRenderEngine
debe atenuar el contenido. Esto acomodaColorModes
definidos por el proveedor, que pueden preferir atenuarse en el espacio gamma, para permitir mejoras de contraste definidas por el proveedor en sus canalizaciones de color.Adición de un nuevo tipo de composición
DISPLAY_DECORATION
enComposition.aidl
para decoraciones de pantalla.Algunos dispositivos tienen hardware dedicado para optimizar el dibujo de la máscara alfa que suaviza las esquinas redondeadas y los recortes en las pantallas. Los dispositivos con dicho hardware deben implementar
IComposerClient.getDisplayDecorationSupport
para devolver una estructuraDisplayDecorationSupport
como se define en el nuevoDisplayDecorationSupport.aidl
. Esta estructura describe las enumeracionesPixelFormat
yAlphaInterpretation
requeridas por el dispositivo. Tras esta implementación, la interfaz de usuario del sistema marca la capa de máscara alfa comoDISPLAY_DECORATION
, un nuevo tipo de composición que aprovecha el hardware dedicado.Adición de un nuevo campo
expectedPresentTime
aDisplayCommand.aidl
.El campo
expectedPresentTime
permite que SurfaceFlinger establezca la hora actual esperada en la que se debe mostrar el contenido actual en la pantalla. Con esta función, SurfaceFlinger envía un comando presente a la implementación con anticipación, lo que le permite canalizar más trabajo de composición.Adición de nuevas API para controlar la configuración de visualización de arranque.
Con
BOOT_DISPLAY_CONFIG
, los proveedores pueden especificar que se admita la configuración de la pantalla de arranque. Los métodossetBootDisplayConfig
,clearBootDisplayConfig
ygetPreferredBootDisplayConfig
usanBOOT_DISPLAY_CONFIG
de la siguiente manera:Usando
setBootDisplayConfig
, el marco informa a los proveedores de la configuración de visualización del tiempo de arranque. Los proveedores deben almacenar en caché la configuración de la pantalla de arranque y arrancar con esta configuración en el próximo reinicio. Si el dispositivo no puede iniciarse en 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 visualización preferida.Al usar
clearBootDisplayConfig
, el marco informa a los proveedores que borren la configuración de visualización de inicio y que inicien en su configuración de visualización preferida durante el próximo reinicio.Con
getPreferredBootDisplayConfig
, el marco consulta el modo de inicio preferido del proveedor.
Cuando la configuración de visualización de inicio no es compatible, estos métodos devuelven un valor de
UNSUPPORTED
.Adición de nuevas API para controlar el temporizador de inactividad de la pantalla.
Usando
DISPLAY_IDLE_TIMER
, los proveedores pueden especificar que el proveedor implemente un temporizador de inactividad para esta pantalla. Cuando está inactivo, esta capacidad cambia la frecuencia de actualización a una configuración más baja para ahorrar energía. La plataforma usasetIdleTimerEnabled
para controlar el tiempo de espera del temporizador y, en algunos casos, para deshabilitarlo a fin de evitar cambios de frecuencia de actualización no deseados cuando está inactivo.El uso de la devolución de llamada
IComposerCallback.onVsyncIdle
indica a la plataforma que la pantalla está inactiva y que la cadenciavsync
ha cambiado. La plataforma responde a esta devolución de llamada restableciendo su modelovsync
. Fuerza una resincronizaciónvsync
en el siguiente cuadro y aprende la nueva cadenciavsync
.
Implementación
No se requiere que los proveedores implementen AIDL HAL para Android 13. Sin embargo, se les anima a implementar AIDL composer HAL en lugar de la versión HIDL para usar la nueva funcionalidad y las nuevas API.
Una implementación de referencia para AIDL HWC HAL se implementa en emuladores de Android.
Pruebas
Para probar su implementación, ejecute VtsHalGraphicsComposer3_TargetTest
.