Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Se usó la API de Cloud Translation para traducir esta página.

AIDL para el compositor de hardware HAL

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 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 los comandos 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 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 en LayerCommand 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 en ClientTargetPropertyWithBrightness le permite al HWC especificar el espacio de brillo para la composición del cliente e indicar RenderEngine si debe atenuar las capas SDR en la composición del cliente.
El campo dimmingStage permite que HWC configure cuándo RenderEngine debe atenuar el contenido. Esto acomoda ColorModes 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 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 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étodos setBootDisplayConfig , clearBootDisplayConfig y getPreferredBootDisplayConfig usan BOOT_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 usa setIdleTimerEnabled 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 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 cuadro y aprende la nueva cadencia vsync .

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 .