A partire da Android 13, l'HAL Hardware Composer (HWC)
è definito in AIDL. Le versioni HIDL comprese tra
android.hardware.graphics.composer@2.1
e
android.hardware.graphics.composer@2.4
sono ritirate.
Questa pagina descrive le differenze tra le HAL AIDL e HIDL per HWC e come implementare e testare la HAL AIDL.
Poiché AIDL offre vantaggi, i fornitori possono implementare l'HAL Composer AIDL a partire da Android 13 anziché dalla versione HIDL. Per ulteriori informazioni, consulta la sezione Implementazione.
Differenze tra HAL AIDL e HIDL
Il nuovo HAL del compositore AIDL, denominato android.hardware.graphics.composer3
, è
definito in IComposer.aidl
. L'API è simile all'HAL HIDL
android.hardware.graphics.composer@2.4
, ma include le seguenti modifiche:
Rimozione della Fast Message Queue (FMQ) a favore dei comandi parcelable.
L'HAL AIDL definisce l'interfaccia dei comandi in base a tipi parcelable fortemente tipizzati anziché ai comandi serializzati su FMQ in HIDL. In questo modo viene fornita un'interfaccia stabile per i comandi e una definizione più leggibile di come il sistema interpreta il payload del comando.
Il metodo
executeCommands
5 è definito inIComposerClient.aidl
:CommandResultPayload[] executeCommands(in DisplayCommand[] commands);
Ogni comando è un tipo parcelable fortemente tipizzato definito in
DisplayCommand.aidl
. Le risposte ai comandi sono parcelable fortemente tipizzati definiti inCommandResultPayload.aidl
.Rimozione di
IComposerClient.getClientTargetSupport
perché nessun client attivo utilizza questo metodo.Rappresentazione dei colori come numeri in virgola mobile anziché byte per allinearsi allo stack grafico superiore in Android, come definito da
ASurfaceTransaction_setColor
.Aggiunta di nuovi campi per il controllo dei contenuti HDR.
Nell'HAL AIDL, gli stack di livelli SDR/HDR misti supportano l'attenuazione uniforme dei livelli SDR quando un livello HDR è sullo schermo contemporaneamente.
Il campo
brightness
inLayerCommand
consente a SurfaceFlinger di specificare una luminosità per livello. Ciò consente all'HWC di oscurare il contenuto del livello nello spazio di luce lineare anziché nello spazio gamma.Il campo
brightness
inClientTargetPropertyWithBrightness
consente all'HWC di specificare lo spazio di luminosità per la composizione del client e indica aRenderEngine
se oscurare i livelli SDR nella composizione del client.Il campo
dimmingStage
consente al produttore di hardware di configurare quandoRenderEngine
attenua i contenuti. In questo modo, si adattano iColorModes
definiti dal fornitore che potrebbero preferire la riduzione della luminosità nello spazio gamma per consentire i miglioramenti del contrasto definiti dal fornitore nelle pipeline di colore.Aggiunta di un tipo di composizione,
DISPLAY_DECORATION
, inComposition.aidl
per le decorazioni dello schermo.Alcuni dispositivi hanno hardware dedicato per ottimizzare il disegno della maschera alfa che smussa gli angoli arrotondati e le tacche sui display. I dispositivi con questo hardware devono implementare
IComposerClient.getDisplayDecorationSupport
e restituire una strutturaDisplayDecorationSupport
come definito inDisplayDecorationSupport.aidl
. Questa struttura descrive gli enumPixelFormat
eAlphaInterpretation
richiesti dal dispositivo. Dopo questa implementazione, la UI di sistema contrassegna il livello della maschera alfa comeDISPLAY_DECORATION
, un tipo di composizione che sfrutta l'hardware dedicato.Aggiunta di un campo
expectedPresentTime
aDisplayCommand.aidl
.Il campo
expectedPresentTime
consente a SurfaceFlinger di impostare l'ora di presentazione prevista per la visualizzazione dei contenuti attuali sullo schermo. Con questa funzionalità, SurfaceFlinger invia un comando di presentazione all'implementazione in anticipo, il che consente di eseguire il pipeline di una parte maggiore del lavoro di composizione.Aggiunta di nuove API per controllare la configurazione di visualizzazione dell'avvio.
Utilizzando
BOOT_DISPLAY_CONFIG
, i fornitori possono specificare che la configurazione dello schermo di avvio è supportata. I metodisetBootDisplayConfig
,clearBootDisplayConfig
egetPreferredBootDisplayConfig
utilizzanoBOOT_DISPLAY_CONFIG
come segue:Utilizzando
setBootDisplayConfig
, il framework informa i fornitori della configurazione di visualizzazione del tempo di avvio. I fornitori devono memorizzare nella cache la configurazione del display di avvio e avviare il sistema con questa configurazione al riavvio successivo. Se il dispositivo non è in grado di avviarsi con questa configurazione, il fornitore deve trovare una configurazione che corrisponda alla risoluzione e alla frequenza di aggiornamento di questa configurazione. Se non esiste una configurazione di questo tipo, il fornitore deve utilizzare la configurazione di visualizzazione preferita.Utilizzando
clearBootDisplayConfig
, il framework comunica ai fornitori di cancellare la configurazione del display di avvio e di eseguire l'avvio nella configurazione del display preferita al riavvio successivo.Utilizzando
getPreferredBootDisplayConfig
, il framework esegue query sulla modalità di avvio preferita del fornitore.
Quando la configurazione del display di avvio non è supportata, questi metodi restituiscono un valore di
UNSUPPORTED
.Aggiunta di nuove API per controllare il timer di inattività del display:
Utilizzando
DISPLAY_IDLE_TIMER
, i fornitori possono specificare che un timer di inattività viene implementato dal fornitore per questo display. Quando è inattiva, questa funzionalità modifica la frequenza di aggiornamento impostando un valore inferiore per risparmiare energia. La piattaforma utilizzasetIdleTimerEnabled
per controllare il timeout del timer e, in alcuni casi, per disattivarlo al fine di evitare cambi indesiderati della frequenza di aggiornamento quando il dispositivo è inattivo.L'utilizzo del callback
IComposerCallback.onVsyncIdle
indica alla piattaforma che il display è inattivo e la cadenzavsync
è cambiata. La piattaforma risponde a questo callback reimpostando il modellovsync
. Forza una risincronizzazionevsync
nel frame successivo e apprende la nuova cadenzavsync
.
Implementazione
I fornitori non sono tenuti a implementare l'HAL AIDL per Android 13. Tuttavia, i fornitori sono invitati a implementare l'HAL del compositore AIDL anziché la versione HIDL per utilizzare le funzionalità e le API dell'HAL del compositore AIDL.
Gli emulatori Android includono un'implementazione di riferimento per l'HAL HWC AIDL.
Test
Per testare l'implementazione, esegui VtsHalGraphicsComposer3_TargetTest
.