AIDL per l'HAL Hardware Composer

A partire da Android 13, l'HAL Hardware Composer (HWC) è definito in AIDL e 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 AIDL e HIDL HAL per HWC e l'implementazione e il test di AIDL HAL.

A causa dei vantaggi offerti da AIDL, i fornitori sono invitati a implementare l'HAL Composer AIDL a partire da Android 13 anziché dalla versione HIDL. Per saperne di più, 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. Espone un'API simile a HIDL HAL android.hardware.graphics.composer@2.4 con le seguenti modifiche:

  • Rimozione della coda di messaggi rapida (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. 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 in IComposerClient.aidl come

    CommandResultPayload[] executeCommands(in DisplayCommand[] commands);

    dove 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 in quanto non ci sono clienti attivi per questo metodo.

  • Rappresentazione dei colori come numeri in virgola mobile 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 SDR/HDR misti supportano l'attenuazione uniforme dei livelli SDR quando un livello HDR è contemporaneamente sullo schermo.

    Il campo brightness in LayerCommand consente a SurfaceFlinger di specificare una luminosità per livello, in modo che HWC attenui il contenuto del livello nello spazio di luce lineare, anziché nello spazio gamma.

    Il campo brightness in ClientTargetPropertyWithBrightness consente all'HWC di specificare lo spazio di luminosità per la composizione del client e di indicare a RenderEngine se oscurare i livelli SDR nella composizione del client.

    Il campo dimmingStage consente all'HWC di configurare quando RenderEngine deve oscurare i contenuti. In questo modo vengono presi in considerazione i ColorModes definiti dal fornitore, che potrebbero preferire la riduzione della luminosità nello spazio gamma, per consentire i miglioramenti del contrasto definiti dal fornitore nelle pipeline del colore.

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

    Alcuni dispositivi dispongono di hardware dedicato per ottimizzare il disegno della maschera alfa che rende più uniformi gli angoli arrotondati e le tacche sui display. I dispositivi con questo hardware devono implementare IComposerClient.getDisplayDecorationSupport per restituire una struttura DisplayDecorationSupport come definita nel nuovo DisplayDecorationSupport.aidl. Questa struttura descrive gli enum PixelFormat e AlphaInterpretation richiesti dal dispositivo. Dopo questa implementazione, la UI di sistema contrassegna il livello della maschera alfa come DISPLAY_DECORATION, un nuovo tipo di composizione che sfrutta l'hardware dedicato.

  • Aggiunta di un nuovo campo expectedPresentTime a DisplayCommand.aidl.

    Il campo expectedPresentTime consente a SurfaceFlinger di impostare l'ora di presentazione prevista per il momento in cui i contenuti attuali devono essere visualizzati sullo schermo. Con questa funzionalità, SurfaceFlinger invia un comando di presentazione all'implementazione in anticipo, consentendo 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 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 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 successivo riavvio. Se il dispositivo non riesce ad 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 che preferisce.

    • 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à venga implementato dal fornitore per questo display. Quando è inattiva, questa funzionalità modifica la frequenza di aggiornamento a un'impostazione inferiore per risparmiare energia. La piattaforma utilizza setIdleTimerEnabled 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 che la cadenza vsync è cambiata. La piattaforma risponde a questo callback reimpostando il modello vsync. Forza una risincronizzazione vsync nel frame successivo e apprende la nuova cadenza vsync.

Implementazione

I fornitori non sono tenuti a implementare l'HAL AIDL per Android 13. Tuttavia, sono invitati a implementare l'HAL del compositore AIDL anziché la versione HIDL per utilizzare le nuove funzionalità e API.

Un'implementazione di riferimento per l'HWC HAL AIDL è implementata negli emulatori Android.

Test

Per testare l'implementazione, esegui VtsHalGraphicsComposer3_TargetTest.