AIDL per l'HAL Hardware Composer

A partire da Android 13, l'HAL Hardware Composer (HWC) è definito in AIDL. Le versioni HIDL che vanno da android.hardware.graphics.composer@2.1 a android.hardware.graphics.composer@2.4 sono obsolete.

Questa pagina descrive le differenze tra gli HAL AIDL e HIDL per HWC e come implementare e testare l'HAL AIDL.

Poiché AIDL offre vantaggi, i fornitori possono implementare l'AIDL HAL del compositore a partire da Android 13 anziché la versione HIDL. Per ulteriori informazioni, consulta la sezione Implementazione.

Differenze tra gli 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 coda di messaggi veloce (FMQ) a favore dei comandi parcelable.

    L'HAL AIDL definisce l'interfaccia dei comandi in base ai 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 dei comandi.

    Il metodo executeCommands 5 è definito in IComposerClient.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 in CommandResultPayload.aidl.

  • Rimozione di IComposerClient.getClientTargetSupport perché nessun client attivo utilizza questo metodo.

  • Rappresentazione dei colori come valori float 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 layer SDR/HDR misti supportano l'attenuazione continua dei layer SDR quando un layer HDR è contemporaneamente sullo schermo.

    Il campo brightness in LayerCommand consente a SurfaceFlinger di specificare una luminosità per layer. In questo modo, HWC può attenuare il contenuto del layer nello spazio di luce lineare anziché nello spazio gamma.

    Il campo brightness in ClientTargetPropertyWithBrightness consente a HWC di specificare lo spazio di luminosità per la composizione del client e indica a RenderEngine se attenuare i layer SDR nella composizione del client.

    Il campo dimmingStage consente a HWC di configurare quando RenderEngine attenua i contenuti. In questo modo, vengono supportate le ColorModes definite dal fornitore che potrebbero preferire l'attenuazione nello spazio gamma per abilitare i miglioramenti del contrasto definiti dal fornitore nelle pipeline di colore.

  • Aggiunta di un tipo di composizione, DISPLAY_DECORATION, in Composition.aidl per le decorazioni dello schermo.

    Alcuni dispositivi hanno hardware dedicato per ottimizzare il disegno della maschera alfa che uniforma gli angoli arrotondati e i ritagli sui display. I dispositivi con questo hardware devono implementare IComposerClient.getDisplayDecorationSupport e restituire una struttura DisplayDecorationSupport come definita in DisplayDecorationSupport.aidl. Questa struttura descrive gli PixelFormat e AlphaInterpretation enum richiesti dal dispositivo. Dopo questa implementazione, l'UI di sistema contrassegna il layer della maschera alfa come DISPLAY_DECORATION, un tipo di composizione che sfrutta l'hardware dedicato.

  • Aggiunta di un expectedPresentTime campo a DisplayCommand.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 in anticipo un comando di presentazione all'implementazione, che consente di eseguire in pipeline una parte maggiore del lavoro di composizione.

  • Aggiunta di nuove API per controllare la configurazione del display di avvio.

    Utilizzando BOOT_DISPLAY_CONFIG, i fornitori possono specificare che la configurazione del display di avvio è supportata. I metodi setBootDisplayConfig, clearBootDisplayConfig e getPreferredBootDisplayConfig utilizzano BOOT_DISPLAY_CONFIG come segue:

    • Utilizzando setBootDisplayConfig, il framework informa i fornitori della configurazione del display di avvio. I fornitori devono memorizzare nella cache la configurazione del display di avvio ed eseguire l'avvio in questa configurazione al riavvio successivo. Se il dispositivo non è in grado di eseguire l'avvio in 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 del display preferita.

    • Utilizzando clearBootDisplayConfig, il framework informa i fornitori di cancellare la configurazione del display di avvio ed eseguire l'avvio nella configurazione del display preferita durante il riavvio successivo.

    • Utilizzando getPreferredBootDisplayConfig, il framework esegue una 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à è implementato dal fornitore per questo display. Quando è inattiva, questa funzionalità modifica la frequenza di aggiornamento impostando un valore inferiore per preservare l'energia. La piattaforma utilizza setIdleTimerEnabled per controllare il timeout del timer e, in alcuni casi, per disabilitarlo al fine di impedire cambi indesiderati della frequenza di aggiornamento quando è inattiva.

    • L'utilizzo del callback IComposerCallback.onVsyncIdle indica a lla piattaforma che il display è inattivo e che la cadenza vsync è cambiata. La piattaforma risponde a questo callback reimpostando il modello vsync. Forza una risincronizzazione vsync sul frame successivo e apprende la nuova cadenza vsync.

Implementazione

I fornitori non sono tenuti a implementare l'HAL AIDL per Android 13. Tuttavia, i fornitori sono invitati a implementare l' AIDL HAL del compositore 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.