AIDL para la HAL de Hardware Composer

A partir de Android 13, la HAL de Hardware Composer (HWC) se define en AIDL, y las versiones 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 el AIDL y la HAL del HIDL para el HWC, así como la implementación y la prueba de la HAL del AIDL.

Debido a las ventajas que ofrece el AIDL, se recomienda a los proveedores implementar la HAL del compositor del AIDL a partir de Android 13 en lugar de la versión de HIDL. Consulta la sección Implementación para obtener más información.

Diferencias entre las HAL del AIDL y las HAL de HIDL

La nueva HAL de AIDL composer, llamada android.hardware.graphics.composer3, se define en IComposer.aidl. Expone una API similar a la HAL de HIDL android.hardware.graphics.composer@2.4 con los siguientes cambios:

• Eliminación de la cola de mensajes rápidos (FMQ) a favor de los comandos parcelables.

  El HAL de AIDL define la interfaz de comandos en función de tipos parcelables fuertemente tipados, 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 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 con tipo especificado definido en DisplayCommand.aidl. Las respuestas de comando son parcelables de tipo seguro que se definen en CommandResultPayload.aidl.

• Se quitó IComposerClient.getClientTargetSupport porque no hay clientes activos para este método.

• Representación de colores como números de punto flotante en lugar de bytes para alinearse mejor con la pila de gráficos superior en Android, como se define en 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 hay una capa de HDR en pantalla de forma simultánea.

  El campo brightness de LayerCommand permite que SurfaceFlinger especifique un brillo por capa, de modo que HWC atenúe el contenido de la capa en el espacio de luz lineal, en lugar de hacerlo en el espacio de gamma.

  El campo brightness en ClientTargetPropertyWithBrightness permite que el HWC especifique el espacio de brillo para la composición del cliente y le indique a 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 admite ColorModes definido por el proveedor, que podría preferir atenuarse en el espacio gamma para permitir mejoras de contraste definidas por el proveedor en sus canalizaciones de colores.

• Se agregó un nuevo tipo de composición DISPLAY_DECORATION en Composition.aidl para las decoraciones de la 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 ese hardware deben implementar IComposerClient.getDisplayDecorationSupport para mostrar una estructura DisplayDecorationSupport, como se define en el nuevo DisplayDecorationSupport.aidl. Esta estructura describe las enumeraciones PixelFormat y AlphaInterpretation que requiere el dispositivo. Después de esta implementación, la IU del sistema marca la capa de máscara alfa como DISPLAY_DECORATION, un nuevo tipo de composición que aprovecha el hardware dedicado.

• Se agregó un nuevo campo expectedPresentTime a DisplayCommand.aidl.

  El campo expectedPresentTime permite que SurfaceFlinger establezca la hora actual esperada para el momento en que 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 del 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 la pantalla de inicio. Los métodos setBootDisplayConfig, clearBootDisplayConfig y getPreferredBootDisplayConfig usan BOOT_DISPLAY_CONFIG de la siguiente manera:

  • Con setBootDisplayConfig, el framework informa a los proveedores sobre la configuración de visualización de la hora de inicio. Los proveedores deben almacenar en caché la configuración de la pantalla de inicio y, luego, iniciarse con esta configuración en el próximo reinicio. Si el dispositivo no puede iniciarse 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 visualización preferida.

  • Con clearBootDisplayConfig, el framework informa a los proveedores que borren la configuración de pantalla de inicio y que inicien su configuración de pantalla preferida durante el próximo reinicio.

  • Con getPreferredBootDisplayConfig, el framework consulta el modo de inicio preferido del proveedor.

  Cuando no se admite la configuración de la pantalla de inicio, estos métodos muestran 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 el proveedor implemente un temporizador de inactividad para esta pantalla. Cuando está inactiva, esta función cambia la frecuencia de actualización a una configuración más baja para conservar energía. La plataforma usa setIdleTimerEnabled para controlar el tiempo de espera del temporizador y, en algunos casos, inhabilitarlo a fin de evitar cambios no deseados en la frecuencia de actualización cuando está inactivo.

  • El uso de la devolución de llamada IComposerCallback.onVsyncIdle le indica a la plataforma que la pantalla está inactiva y que cambió la cadencia de vsync. La plataforma responde a esta devolución de llamada restableciendo su modelo vsync. Fuerza una resincronización de vsync en el siguiente fotograma y aprende la nueva cadencia de vsync.

Implementación

Los proveedores no necesitan implementar la HAL del AIDL para Android 13. Sin embargo, se recomienda implementar el HAL del compilador AIDL en lugar de la versión HIDL para usar las nuevas funciones y APIs.

En los emuladores de Android, se implementa una implementación de referencia para la HAL de HWC del AIDL.

Prueba

Para probar tu implementación, ejecuta VtsHalGraphicsComposer3_TargetTest.