AIDL per Hardware Composer HAL

A partire da Android 13, l'HWC (Hardware Composer) è definito in AIDL e le versioni HIDL comprese tra android.hardware.graphics.composer@2.1 e android.hardware.graphics.composer@2.4 sono deprecate.

Questa pagina descrive le differenze tra l'HAL AIDL e l'HAL HIDL per l'HWC, nonché l'implementazione e il test dell'HAL AIDL.

A causa dei vantaggi offerti da AIDL, i fornitori sono invitati a implementare il compilatore HAL AIDL a partire da Android 13 anziché la 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 all'HAL HIDLandroid.hardware.graphics.composer@2.4 con le seguenti modifiche:

  • Rimozione della coda di messaggi rapida (FMQ) in favore dei comandi parcellabili.

    AIDL HAL definisce l'interfaccia di comando in base a tipi di dati Parcelable (con elevata digitazione) anziché tramite comandi serializzati su FMQ in HIDL. In questo modo viene fornita 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 al comando sono valori parcelabili fortemente digitati definiti in CommandResultPayload.aidl.

  • Rimozione di IComposerClient.getClientTargetSupport perché non ci sono client attivi per questo metodo.

  • Rappresentazione dei colori come numeri in virgola mobile anziché byte per allinearsi meglio allo stack grafico superiore in Android definito in ASurfaceTransaction_setColor.

  • Aggiunta di nuovi campi per il controllo dei contenuti HDR.

    Nell'HAL AIDL, le serie di livelli SDR/HDR misti supportano l'attenuazione uniforme dei livelli SDR quando sullo schermo è presente contemporaneamente un livello HDR.

    Il campo brightness in LayerCommand consente a SurfaceFlinger di specificare una luminosità per livello, in modo che l'HWC attenua 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 attenuare i livelli SDR nella composizione del client.

    Il campo dimmingStage consente all'HWC di configurare quando RenderEngine deve attenuare i contenuti. Questo include ColorModes definito dal fornitore, che potrebbe preferire la riduzione dello spazio intervallo, per consentire miglioramenti del contrasto definiti dal fornitore nelle pipeline di colore.

  • È stato aggiunto 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 smussa gli angoli arrotondati e i ritagli 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 i livelli PixelFormat e AlphaInterpretation richiesti dal dispositivo. In seguito a questa implementazione, l'interfaccia utente di sistema contrassegna il livello della maschera alfa come DISPLAY_DECORATION, un nuovo tipo di composizione che sfrutta l'hardware dedicato.

  • È stato aggiunto un nuovo campo expectedPresentTime a DisplayCommand.aidl.

    Il campo expectedPresentTime consente a SurfaceFlinger di impostare il momento attuale previsto su quando il contenuto corrente deve essere visualizzato sullo schermo. Con questa funzionalità, SurfaceFlinger invia un comando di invio all'implementazione in anticipo, consentendo di eseguire in pipeline una maggiore parte del lavoro di composizione.

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

    Utilizzando BOOT_DISPLAY_CONFIG, i fornitori possono specificare se 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 della visualizzazione del tempo di avvio. I fornitori devono memorizzare nella cache la configurazione di visualizzazione del boot e avviarsi in questa configurazione al successivo riavvio. Se il dispositivo non riesce ad avviarsi 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 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 di visualizzazione preferita al 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 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. In stato di inattività, questa funzionalità modifica la frequenza di aggiornamento impostandola su un valore 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 in stato di inattività.

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

Implementazione

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

Negli emulatori Android è implementata un'implementazione di riferimento per l'HAL HWC AIDL.

Test

Per testare l'implementazione, esegui VtsHalGraphicsComposer3_TargetTest.