Las capacidades de visualización (como los modos de visualización y los tipos de HDR compatibles) pueden cambiar dinámicamente en dispositivos que tienen pantallas conectadas de forma externa (con HDMI o DisplayPort), como decodificadores de Android TV (STB) y dispositivos de transmisión libre (OTT). Este cambio puede ocurrir como resultado de una señal de conexión directa HDMI, por ejemplo, cuando el usuario cambia de una pantalla a otra o inicia el dispositivo sin una pantalla conectada. Android 12 y versiones posteriores incluyen cambios en el framework para controlar las capacidades de conexión directa y visualización dinámica.
En esta página, se describe el control de las conexiones directas de la pantalla y los cambios en las capacidades de visualización en la implementación de la HAL de Composer. Además, se explica cómo administrar el búfer de fotogramas asociado y evitar las condiciones de carrera en estas situaciones.
Actualiza las capacidades de visualización
En esta sección, se describe cómo el framework de Android controla los cambios en las capacidades de visualización que inicia la HAL de Composer.
Antes de que Android pueda controlar los cambios en las capacidades de visualización de forma adecuada, el OEM debe
implementar la HAL de Composer de modo que use
onHotplug(display, connection=CONNECTED) para notificar al framework cualquier
cambio en las capacidades de visualización. Una vez que se implementa, Android controla los cambios en las capacidades de visualización de la siguiente manera:
- Cuando se detecta un cambio en las capacidades de visualización, el framework recibe una
onHotplug(display, connection=CONNECTED)notificación. - Cuando recibe la notificación, el framework descarta su estado de visualización y
lo vuelve a crear con las nuevas capacidades de la HAL mediante los métodos
getActiveConfig,getDisplayConfigs,getDisplayAttribute,getColorModes,getHdrCapabilitiesygetDisplayCapabilities. - Después de que el framework vuelve a crear un nuevo estado de visualización, envía la
onDisplayChangeddevolución de llamada a las apps que escuchan esos eventos.
El framework reasigna los búferes de fotogramas en los eventos posteriores
onHotplug(display, connection=CONNECTED). Consulta
Administración de búfer de fotogramas del cliente para obtener más información sobre cómo administrar correctamente
la memoria del búfer de fotogramas para evitar fallas durante la asignación de búferes de fotogramas nuevos.
Controla situaciones de conexión comunes
En esta sección, se explica cómo controlar correctamente varias situaciones de conexión en tus implementaciones cuando la pantalla principal está conectada y desconectada.
Como se creó para dispositivos móviles, el framework de Android no tiene compatibilidad integrada para una pantalla principal desconectada. En cambio, la HAL debe reemplazar la pantalla principal por una pantalla de marcador de posición en sus interacciones con el framework en el caso de que una pantalla principal esté desconectada físicamente.
Las siguientes situaciones pueden ocurrir en decodificadores y dongles de TV que tienen pantallas conectadas de forma externa que se pueden desconectar. Para implementar la compatibilidad con estas situaciones, usa la información de la siguiente tabla:
| Situación | Manipulación |
|---|---|
| No hay ninguna pantalla conectada en el momento del inicio |
|
| La pantalla principal está conectada físicamente |
|
| La pantalla principal está desconectada físicamente |
|
Consideraciones sobre la conexión que no es HDMI
Android TV solo admite las siguientes resoluciones:
- 720x1280
- 1080x1920
- 2160x3840
- 4320x7680
Cuando un decodificador o un dongle de TV intenta mostrar una resolución no admitida, como 480i a través de una conexión CVBS, se muestra un mensaje de error al usuario.
Si el decodificador o el dongle de TV tienen conexiones HDMI y no HDMI, la conexión HDMI es la pantalla principal y la conexión no HDMI está inactiva. Como resultado, si se desconecta la conexión HDMI mientras la conexión no HDMI
sigue conectada, se envía un evento a SurfaceFlinger y las
capacidades de la pantalla no HDMI deben reflejarse a través
getDisplayAttribute y otras IComposerClient APIs (como
getHdrCapabilities).
Usa IDs de configuración secuenciales para evitar condiciones de carrera
Pueden surgir condiciones de carrera si la HAL de Composer actualiza las configuraciones de visualización compatibles
de forma simultánea con el framework que llama a setActiveConfig o
setActiveConfigWithConstraints. La solución es implementar la HAL de Composer para usar IDs secuenciales y evitar este problema.
En esta sección, se describe cómo pueden ocurrir las condiciones de carrera y, luego, se proporcionan detalles sobre cómo implementar la HAL de Composer para que use IDs secuenciales y evite esas condiciones.
Considera la siguiente secuencia de eventos cuando NO se asignan IDs secuenciales nuevos a las nuevas configuraciones de visualización, lo que provoca una condición de carrera:
Los IDs de configuración de visualización compatibles son los siguientes:
- id=1, 1080 x 1920 60 Hz
- id=2, 1080 x 1920 50 Hz
El framework llama a
setActiveConfig(display, config=1).De forma simultánea, la HAL de Composer procesa un cambio de configuraciones de visualización y actualiza su estado interno a un nuevo conjunto de configuraciones de visualización, como se muestra a continuación:
- id=1, 2160 x 3840 60 Hz
- id=2, 2160 x 3840 50 Hz
- id=3, 1080 x 1920 60 Hz
- id=4, 1080 x 1920 50 Hz
La HAL de Composer envía un
onHotplugevento al framework para notificar que cambió el conjunto de modos compatibles.La HAL de Composer recibe
setActiveConfig(display, config=1)(de paso 2).La HAL interpreta que el framework solicitó un cambio de configuración a 2160 x 3840 60 Hz, aunque en realidad se1080 x 1920 60 Hzseleccionó.
El proceso que usa asignaciones de IDs no secuenciales termina aquí con una interpretación errónea del cambio de configuración seleccionado.
Configura la HAL de Composer para usar IDs secuenciales
Para evitar esas condiciones de carrera, el OEM debe implementar la HAL de Composer de la siguiente manera:
- Cuando la HAL de Composer actualiza las configuraciones de visualización compatibles, asigna IDs secuenciales nuevos a las nuevas configuraciones de visualización.
- Cuando el framework llama a
setActiveConfigosetActiveConfigWithConstraintscon un ID de configuración no válido, la HAL de Composer ignora la llamada.
Estos pasos sirven para evitar las condiciones de carrera, como se muestra en el siguiente debate.
Considera la siguiente secuencia de eventos cuando se asignan IDs secuenciales nuevos a las nuevas configuraciones de visualización:
Los IDs de configuración de visualización compatibles son los siguientes:
- id=1, 1080 x 1920 60 Hz
- id=2, 1080 x 1920 50 Hz
El framework llama a
setActiveConfig(display, config=1).Cuando se procesa un cambio de configuraciones de visualización, se asigna el siguiente conjunto de IDs de configuración a partir del siguiente número entero no utilizado, como se muestra a continuación:
id=3, 2160 x 3840 60 Hz
id=4, 2160 x 3840 50 Hz
id=5, 1080 x 1920 60 Hz
id=6, 1080 x 1920 50 Hz
La HAL de Composer envía un
onHotplugevento al framework para notificar que cambió el conjunto de modos compatibles.La HAL de Composer recibe
setActiveConfig(display, config=1)(de paso 2).La HAL de Composer ignora la llamada, ya que el ID ya no es válido.
El framework recibe y procesa el evento
onHotplugdel paso 4. Llama a la HAL de Composer con las funcionesgetDisplayConfigsygetDisplayAttribute. Con estas funciones, el framework identifica el nuevo ID (5) para la resolución y la frecuencia de actualización seleccionadas de 1080 x 1920 y 60 Hz.El framework envía otro
setActiveConfigevento con un ID actualizado de 5.La HAL de Composer recibe
setActiveConfig(display, config=5)de paso 5.La HAL interpreta correctamente que el framework solicitó un cambio de configuración a 1080 x 1920 60 Hz.
Como se muestra en el ejemplo anterior, el proceso que usa asignaciones de IDs secuenciales verifica que se evite la condición de carrera y se actualice el cambio de configuración de visualización correcto.