A partire da Android 13, l'HAL Hardware Composer (HWC) è definito in AIDL e le versioni HIDL che vanno da android.hardware.graphics.composer@2.1
a android.hardware.graphics.composer@2.4
sono deprecate.
Questa pagina descrive le differenze tra AIDL e HIDL HAL per l'HWC e l'implementazione e il test di AIDL HAL.
A causa dei vantaggi offerti da AIDL, i fornitori sono incoraggiati a implementare l'HAL del compositore AIDL a partire da Android 13 invece della versione HIDL. Per ulteriori informazioni vedere la sezione Implementazione .
Differenze tra HAL AIDL e HIDL
Il nuovo HAL del compositore AIDL, denominato android.hardware.graphics.composer3
, è definito in IComposer.aidl
. Espone un'API simile all'HIDL HAL android.hardware.graphics.composer@2.4
con le seguenti modifiche:
Eliminazione della Fast Message Queue (FMQ) a favore dei comandi parcellabili.
L'HAL AIDL definisce l'interfaccia di comando basata su tipi parcellizzati fortemente tipizzati in contrapposizione ai comandi serializzati su FMQ in HIDL. Ciò fornisce un'interfaccia stabile per i comandi e una definizione più leggibile di come viene interpretato il payload del comando.
Il metodo
executeCommands
è definito inIComposerClient.aidl
comeCommandResultPayload[] executeCommands(in DisplayCommand[] commands);
dove ogni comando è un tipo parcellabile fortemente tipizzato definito in
DisplayCommand.aidl
. Le risposte ai comandi sono pacchetti fortemente tipizzati definiti inCommandResultPayload.aidl
.Rimozione di
IComposerClient.getClientTargetSupport
poiché non sono presenti client attivi per questo metodo.Rappresentazione dei colori come float anziché byte per un migliore allineamento con lo stack grafico superiore in Android come definito in
ASurfaceTransaction_setColor
.Aggiunta di nuovi campi per il controllo dei contenuti HDR.
Nell'HAL AIDL, gli stack di livelli misti SDR/HDR supportano l'oscuramento continuo dei livelli SDR quando un livello HDR è contemporaneamente sullo schermo.
Il campo
brightness
inLayerCommand
consente a SurfaceFlinger di specificare una luminosità per livello, in modo che l'HWC oscuri 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 di indicare aRenderEngine
se attenuare i livelli SDR nella composizione del client.Il campo
dimmingStage
consente all'HWC di configurare quandoRenderEngine
deve oscurare il contenuto. Ciò si adatta aiColorModes
definiti dal fornitore, che potrebbero preferire attenuare lo spazio gamma, per consentire miglioramenti del contrasto definiti dal fornitore nelle loro pipeline di colore.Aggiunta di un nuovo tipo di composizione
DISPLAY_DECORATION
inComposition.aidl
per le decorazioni dello schermo.Alcuni dispositivi dispongono di hardware dedicato per ottimizzare il disegno della maschera alfa che smussa gli angoli arrotondati e i ritagli sui display. I dispositivi con tale hardware devono implementare
IComposerClient.getDisplayDecorationSupport
per restituire una strutturaDisplayDecorationSupport
come definita nel nuovoDisplayDecorationSupport.aidl
. Questa struttura descrive le enumerazioniPixelFormat
eAlphaInterpretation
richieste dal dispositivo. Con questa implementazione, l'interfaccia utente del sistema contrassegna il livello della maschera alfa comeDISPLAY_DECORATION
, un nuovo tipo di composizione che sfrutta l'hardware dedicato.Aggiunta di un nuovo campo
expectedPresentTime
aDisplayCommand.aidl
.Il campo
expectedPresentTime
consente a SurfaceFlinger di impostare l'ora presente prevista su quando il contenuto corrente deve essere visualizzato sullo schermo. Con questa funzionalità, SurfaceFlinger invia in anticipo un comando presente all'implementazione, consentendole di elaborare una parte maggiore del lavoro di composizione.Aggiunta di nuove API per controllare la configurazione della visualizzazione di avvio.
Utilizzando
BOOT_DISPLAY_CONFIG
, i fornitori possono specificare che la configurazione della visualizzazione 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 ed eseguire l'avvio in questa configurazione al prossimo riavvio. 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 informa i fornitori di cancellare la configurazione del display di avvio e di eseguire l'avvio nella configurazione del display preferita durante il successivo riavvio.Utilizzando
getPreferredBootDisplayConfig
, il framework interroga la modalità di avvio preferita del fornitore.
Quando la configurazione della visualizzazione di avvio non è supportata, questi metodi restituiscono il valore
UNSUPPORTED
.Aggiunta di nuove API per controllare il timer di inattività del display.
Utilizzando
DISPLAY_IDLE_TIMER
, i fornitori possono specificare che il fornitore implementa un timer di inattività per questo display. Quando è inattivo, questa funzionalità modifica la frequenza di aggiornamento su un valore inferiore per preservare la potenza. La piattaforma utilizzasetIdleTimerEnabled
per controllare il timeout del timer e, in alcuni casi, per disabilitarlo al fine di impedire cambi di frequenza di aggiornamento indesiderati quando inattivo.L'utilizzo del callback
IComposerCallback.onVsyncIdle
indica alla piattaforma che il display è inattivo e che la cadenzavsync
è cambiata. La piattaforma risponde a questa richiamata reimpostando il suo modellovsync
. Forza una risincronizzazionevsync
sul frame successivo e apprende la nuova cadenzavsync
.
Implementazione
I fornitori non sono tenuti a implementare l'HAL AIDL per Android 13. Tuttavia, sono incoraggiati a implementare l'HAL del compositore AIDL invece della versione HIDL per utilizzare le nuove funzionalità e API.
Un'implementazione di riferimento per l'HAL HWC AIDL è implementata negli emulatori Android.
Test
Per testare la tua implementazione, esegui VtsHalGraphicsComposer3_TargetTest
.