Esta página se ha traducido con Cloud Translation API.

AIDL para el compositor de hardware HAL

A partir de Android 13, el HAL del compositor de hardware (HWC) se define en AIDL y las versiones HIDL que van desde android.hardware.graphics.composer@2.1 hasta android.hardware.graphics.composer@2.4 están en desuso.

Esta página describe las diferencias entre AIDL y HIDL HAL para HWC y la implementación y prueba de AIDL HAL.

Debido a las ventajas que ofrece AIDL, se recomienda a los proveedores que implementen el compositor HAL de AIDL 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 AIDL y HIDL HAL

El nuevo compositor AIDL HAL, 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 parcelables.
AIDL HAL define la interfaz de comando basada en tipos parcelables fuertemente tipados en contraposició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 útil del comando.
El método executeCommands se define en IComposerClient.aidl como
```
CommandResultPayload[] executeCommands(in DisplayCommand[] commands);
```
donde cada comando es un tipo parcelable fuertemente tipado definido en DisplayCommand.aidl . Las respuestas de comando son parcelables fuertemente tipados definidos en CommandResultPayload.aidl .
Eliminación de IComposerClient.getClientTargetSupport ya que no hay clientes activos para este método.
Representación de colores como flotantes 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 el contenido HDR.
En AIDL HAL, las pilas de capas mixtas SDR/HDR admiten la atenuación perfecta de las capas SDR cuando una capa HDR está simultáneamente en la pantalla.
El campo brightness en LayerCommand permite a SurfaceFlinger especificar 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 en ClientTargetPropertyWithBrightness permite que el HWC especifique el espacio de brillo para la composición del cliente e indique RenderEngine si debe atenuar las capas SDR en la composición del cliente.
El campo dimmingStage permite que el HWC configure cuándo RenderEngine debe atenuar el contenido. Esto se adapta a ColorModes definidos por el proveedor, que podrían preferir atenuarse en el espacio gamma, para permitir mejoras de contraste definidas por el proveedor en sus canales de color.
Adición de un nuevo tipo de composición DISPLAY_DECORATION en Composition.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 estructura DisplayDecorationSupport como se define en el nuevo DisplayDecorationSupport.aidl . Esta estructura describe las enumeraciones PixelFormat y AlphaInterpretation requeridas por el dispositivo. Tras esta implementación, la interfaz de usuario del sistema marca la capa de máscara alfa como DISPLAY_DECORATION , un nuevo tipo de composición que aprovecha el hardware dedicado.
Adición de un nuevo campo expectedPresentTime a DisplayCommand.aidl .
El campo expectedPresentTime permite a SurfaceFlinger establecer la hora presente esperada en la que se debe mostrar el contenido actual en la pantalla. Con esta característica, 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 inicio.
Usando BOOT_DISPLAY_CONFIG , los proveedores pueden especificar que la configuración de pantalla de inicio sea compatible. Los métodos setBootDisplayConfig , clearBootDisplayConfig y getPreferredBootDisplayConfig usan BOOT_DISPLAY_CONFIG de la siguiente manera:
- Utilizando setBootDisplayConfig , el marco informa a los proveedores sobre la configuración de visualización del tiempo de arranque. Los proveedores deben almacenar en caché la configuración de pantalla de inicio e iniciar en 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 dicha configuración, el proveedor debe utilizar su configuración de pantalla preferida.
- Al utilizar clearBootDisplayConfig , el marco informa a los proveedores que borre la configuración de la pantalla de inicio y arranque en su configuración de pantalla preferida durante el próximo reinicio.
- Usando 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.
- Al utilizar DISPLAY_IDLE_TIMER , los proveedores pueden especificar que el proveedor implemente un temporizador de inactividad para esta pantalla. Cuando está inactiva, esta capacidad cambia la frecuencia de actualización a una configuración más baja para preservar la energía. La plataforma utiliza setIdleTimerEnabled para controlar el tiempo de espera del temporizador y, en algunos casos, para deshabilitarlo para evitar cambios no deseados en la frecuencia de actualización 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 cadencia vsync ha cambiado. La plataforma responde a esta devolución de llamada restableciendo su modelo vsync . Fuerza una resincronización vsync en el siguiente fotograma y aprende la nueva cadencia vsync .

Implementación

Los proveedores no están obligados a implementar AIDL HAL para Android 13. Sin embargo, se les recomienda implementar el compositor AIDL HAL en lugar de la versión HIDL para utilizar la nueva funcionalidad y API.

Se implementa una implementación de referencia para AIDL HWC HAL en emuladores de Android.

Pruebas

Para probar su implementación, ejecute VtsHalGraphicsComposer3_TargetTest .