Le funzionalità di visualizzazione (ad esempio le modalità di visualizzazione e i tipi HDR supportati) possono cambiare dinamicamente sui dispositivi dotati di display collegati esternamente (con HDMI o DisplayPort), ad esempio i decoder Android TV (STB) e i dispositivi over-the-top (OTT). Questo cambiamento può verificarsi a causa di un segnale hot plug HDMI, ad esempio quando l'utente passa da un display all'altro o avvia il dispositivo senza un display collegato. Android 12 e versioni successive includono modifiche al framework per gestire le funzionalità hotplug e di visualizzazione dinamica.
Questa pagina descrive la gestione delle hot plug-in per la visualizzazione e le modifiche alle funzionalità di visualizzazione nell'implementazione di Composer HAL. Inoltre, illustra come gestire il framebuffer associato e prevenire le racecondition in queste situazioni.
Aggiorna le funzionalità del display
Questa sezione descrive in che modo il framework Android gestisce le modifiche nelle funzionalità di visualizzazione avviate da Composer HAL.
Prima che Android possa gestire correttamente le modifiche alle funzionalità di visualizzazione, l'OEM deve
implementare Composer HAL in modo che utilizzi onHotplug(display, connection=CONNECTED)
per notificare al framework eventuali modifiche alle funzionalità di visualizzazione. Una volta implementato, Android gestisce le modifiche alle funzionalità di visualizzazione come segue:
- Quando viene rilevata una modifica delle funzionalità di visualizzazione, il framework riceve una notifica
onHotplug(display, connection=CONNECTED). - Alla ricezione della notifica, il framework rimuove lo stato di visualizzazione e lo ricrea con le nuove funzionalità dell'HAL utilizzando i metodi
getActiveConfig,getDisplayConfigs,getDisplayAttribute,getColorModes,getHdrCapabilitiesegetDisplayCapabilities. - Dopo aver ricreato un nuovo stato di visualizzazione, il framework invia il callback di
onDisplayChangedalle app che ascoltano questi eventi.
Il framework rialloca i framebuffer negli eventi onHotplug(display, connection=CONNECTED)
successivi. Consulta Gestione del framebuffer del client per ulteriori informazioni su come gestire correttamente la memoria del framebuffer per evitare errori durante l'allocazione di nuovi framebuffer.
Gestire scenari di connessione comuni
Questa sezione illustra come gestire correttamente i vari scenari di connessione nelle implementazioni quando il display principale è collegato e disconnesso.
Essendo stato realizzato per i dispositivi mobili, il framework Android non dispone del supporto integrato per un display principale disconnesso. L'HAL deve invece sostituire il display principale con un display segnaposto nelle sue interazioni con il framework nel caso in cui un display principale sia fisicamente disconnesso.
Potrebbero verificarsi i seguenti scenari in STB e dongle TV con display collegati esternamente che possono essere disconnessi. Per implementare l'assistenza per questi scenari, utilizza le informazioni nella tabella seguente:
| Scenario | Prescrizioni d'uso |
|---|---|
| Nessun display collegato al momento dell'avvio |
|
| Il display principale è collegato fisicamente |
|
| Il display principale è fisicamente disconnesso |
|
Considerazioni sulle connessioni non HDMI
Android TV supporta soltanto le seguenti risoluzioni:
- 720x1280
- 1080x1920
- 2160x3840
- 4320x7680
Quando una chiavetta STB o TV tenta di visualizzare una risoluzione non supportata, ad esempio 480i tramite una connessione CVBS, viene mostrato un messaggio di errore all'utente.
Se il dongle STB o TV ha connessioni HDMI e non HDMI, la connessione HDMI è il display principale e la connessione non HDMI è inattiva. Di conseguenza, se la connessione HDMI viene disconnessa mentre la connessione non HDMI
è ancora connessa, viene inviato un evento a SurfaceFlinger e le
funzionalità del display non HDMI devono essere riflesse tramite getDisplayAttribute
e altre API iComposerClient (ad esempio getHdrCapabilities).
Utilizzare gli ID di configurazione sequenziali per evitare le condizioni di gara
Possono verificarsi gare se l'HAL Composer aggiorna le configurazioni di visualizzazione supportate in concomitanza con il framework che chiama setActiveConfig o setActiveConfigWithConstraints.
La soluzione consiste nell'implementare Composer HAL in modo da utilizzare ID sequenziali e prevenire questo problema.
Questa sezione descrive come potrebbero verificarsi le condizioni di gara, seguite dai dettagli su come implementare Composer HAL in modo che utilizzi ID sequenziali per evitare queste condizioni.
Considera la seguente sequenza di eventi, quando NON vengono assegnati nuovi ID sequenziali alle nuove configurazioni di visualizzazione, causando una condizione di gara:
Gli ID configurazione display supportati sono:
- id=1, 1080x1920 a 60 Hz
- id=2, 1080x1920 50 Hz
Il framework chiama
setActiveConfig(display, config=1).Contemporaneamente, Composer HAL elabora una modifica delle configurazioni di visualizzazione e aggiorna il proprio stato interno a un nuovo insieme di configurazioni di visualizzazione, come mostrato di seguito:
- id=1, 2160x3840 60 Hz
- id=2, 2160x3840 50 Hz
- id=3, 1080x1920 a 60 Hz
- id=4, 1080x1920 50 Hz
Composer HAL invia un evento
onHotplugal framework per notificare che il set di modalità supportate è cambiato.Composer HAL riceve
setActiveConfig(display, config=1)(dal passaggio 2).L'HAL interpreta che il framework ha richiesto una modifica della configurazione a 2160x3840 60 Hz, anche se in realtà è stata desiderata 1080x1920 60 Hz.
Il processo che utilizza assegnazioni di ID non sequenziali termina qui con un'interpretazione errata della modifica alla configurazione desiderata.
Configura Composer HAL per l'utilizzo di ID sequenziali
Per evitare queste condizioni di gara, l'OEM deve implementare l'HAL Composer come segue:
- Quando Composer HAL aggiorna le configurazioni di visualizzazione supportate, assegna nuovi ID sequenziali alle nuove configurazioni di visualizzazione.
- Quando il framework chiama
setActiveConfigosetActiveConfigWithConstraintscon un ID di configurazione non valido, Composer HAL ignora la chiamata.
Questi passaggi servono a impedire le racecondition, come mostrato nella discussione seguente.
Considera la seguente sequenza di eventi, quando vengono assegnati nuovi ID sequenziali alle nuove configurazioni display:
Gli ID configurazione display supportati sono:
- id=1, 1080x1920 a 60 Hz
- id=2, 1080x1920 50 Hz
Il framework chiama
setActiveConfig(display, config=1).Quando viene elaborata una modifica delle configurazioni di visualizzazione, il set successivo di ID configurazione viene assegnato a partire dal successivo numero intero inutilizzato, come mostrato di seguito:
id=3, 2160x3840 60 Hz
id=4, 2160x3840 50 Hz
id=5, 1080x1920 a 60 Hz
id=6, 1080x1920 50 Hz
Composer HAL invia un evento
onHotplugal framework per notificare che il set di modalità supportate è cambiato.Composer HAL riceve
setActiveConfig(display, config=1)(dal passaggio 2).L'HAL Composer ignora la chiamata perché l'ID non è più valido.
Il framework riceve ed elabora l'evento
onHotplugdel passaggio 4. Effettua chiamate a Composer HAL utilizzando le funzionigetDisplayConfigsegetDisplayAttribute. Con queste funzioni il framework identifica il nuovo ID (5) per la risoluzione e la frequenza di aggiornamento desiderate di 1080 x 1920 e 60 Hz.Il framework invia un altro evento
setActiveConfigcon un ID aggiornato pari a 5.Composer HAL riceve
setActiveConfig(display, config=5)dal passaggio 5.L'HAL interpreta correttamente che il framework ha richiesto una modifica della configurazione a 1080x1920 60 Hz.
Come mostrato nell'esempio precedente, il processo che utilizza assegnazioni di ID sequenziali garantisce che la condizione di gara venga impedita e che venga aggiornata la modifica corretta alla configurazione di visualizzazione.