À partir d’Android 13, le HAL Hardware Composer (HWC) est défini dans AIDL et les versions HIDL allant de android.hardware.graphics.composer@2.1
à android.hardware.graphics.composer@2.4
sont obsolètes.
Cette page décrit les différences entre l'AIDL et le HIDL HAL pour le HWC ainsi que la mise en œuvre et les tests de l'AIDL HAL.
En raison des avantages offerts par AIDL, les fournisseurs sont encouragés à implémenter le compositeur AIDL HAL à partir d'Android 13 au lieu de la version HIDL. Voir la section Mise en œuvre pour plus d'informations.
Différences entre les HAL AIDL et HIDL
Le nouveau compositeur AIDL HAL, nommé android.hardware.graphics.composer3
, est défini dans IComposer.aidl
. Il expose une API similaire au HIDL HAL android.hardware.graphics.composer@2.4
avec les modifications suivantes :
Suppression de la Fast Message Queue (FMQ) au profit de commandes parcellaires.
L'AIDL HAL définit l'interface de commande basée sur des types parcellaires fortement typés par opposition aux commandes sérialisées sur FMQ dans HIDL. Cela fournit une interface stable pour les commandes et une définition plus lisible de la façon dont la charge utile de la commande est interprétée.
La méthode
executeCommands
est définie dansIComposerClient.aidl
commeCommandResultPayload[] executeCommands(in DisplayCommand[] commands);
où chaque commande est un type parcellaire fortement typé défini dans
DisplayCommand.aidl
. Les réponses aux commandes sont des parcelles fortement typées définies dansCommandResultPayload.aidl
.Suppression de
IComposerClient.getClientTargetSupport
car il n’y a aucun client actif pour cette méthode.Représentation des couleurs sous forme de flottants au lieu d'octets pour mieux s'aligner sur la pile graphique supérieure dans Android telle que définie dans
ASurfaceTransaction_setColor
.Ajout de nouveaux champs pour contrôler le contenu HDR.
Dans AIDL HAL, les piles de couches mixtes SDR/HDR prennent en charge l'atténuation transparente des couches SDR lorsqu'une couche HDR est simultanément à l'écran.
Le champ
brightness
dansLayerCommand
permet à SurfaceFlinger de spécifier une luminosité par couche, de sorte que HWC atténue le contenu de la couche dans un espace lumineux linéaire, par opposition à l'espace gamma.Le champ
brightness
dansClientTargetPropertyWithBrightness
permet au HWC de spécifier l'espace de luminosité pour la composition du client et d'indiquer àRenderEngine
s'il doit atténuer les couches SDR dans la composition du client.Le champ
dimmingStage
permet au HWC de configurer le moment oùRenderEngine
doit atténuer le contenu. Cela prend en chargeColorModes
définis par le fournisseur, qui peuvent préférer atténuer l'espace gamma, pour permettre des améliorations de contraste définies par le fournisseur dans leurs pipelines de couleurs.Ajout d'un nouveau type de composition
DISPLAY_DECORATION
dansComposition.aidl
pour les décorations d'écran.Certains appareils disposent d'un matériel dédié pour optimiser le dessin du masque alpha qui lisse les coins arrondis et les découpes sur les écrans. Les appareils dotés d'un tel matériel doivent implémenter
IComposerClient.getDisplayDecorationSupport
pour renvoyer une structureDisplayDecorationSupport
telle que définie dans le nouveauDisplayDecorationSupport.aidl
. Cette structure décrit les énumérationsPixelFormat
etAlphaInterpretation
requises par l'appareil. Lors de cette implémentation, System UI marque la couche de masque alpha commeDISPLAY_DECORATION
, un nouveau type de composition qui tire parti du matériel dédié.Ajout d'un nouveau champ
expectedPresentTime
àDisplayCommand.aidl
.Le champ
expectedPresentTime
permet à SurfaceFlinger de définir l'heure actuelle attendue à laquelle le contenu actuel doit être affiché à l'écran. Avec cette fonctionnalité, SurfaceFlinger envoie une commande actuelle à l'implémentation à l'avance, lui permettant de canaliser une plus grande partie du travail de composition.Ajout de nouvelles API pour contrôler la configuration de l'affichage de démarrage.
À l'aide
BOOT_DISPLAY_CONFIG
, les fournisseurs peuvent spécifier que la configuration de l'affichage de démarrage est prise en charge. Les méthodessetBootDisplayConfig
,clearBootDisplayConfig
etgetPreferredBootDisplayConfig
utilisentBOOT_DISPLAY_CONFIG
comme suit :À l'aide
setBootDisplayConfig
, le framework informe les fournisseurs de la configuration de l'affichage de l'heure de démarrage. Les fournisseurs doivent mettre en cache la configuration de l'affichage de démarrage et démarrer dans cette configuration au prochain redémarrage. Si le périphérique ne parvient pas à démarrer dans cette configuration, le fournisseur doit trouver une configuration correspondant à la résolution et au taux de rafraîchissement de cette configuration. Si aucune configuration de ce type n’existe, le fournisseur doit utiliser sa configuration d’affichage préférée.À l'aide de
clearBootDisplayConfig
, le framework informe les fournisseurs d'effacer la configuration de l'affichage de démarrage et de démarrer dans leur configuration d'affichage préférée lors du prochain redémarrage.À l'aide de
getPreferredBootDisplayConfig
, le framework interroge le mode de démarrage préféré du fournisseur.
Lorsque la configuration de l'affichage de démarrage n'est pas prise en charge, ces méthodes renvoient la valeur
UNSUPPORTED
.Ajout de nouvelles API pour contrôler la minuterie d'inactivité de l'affichage.
À l'aide
DISPLAY_IDLE_TIMER
, les fournisseurs peuvent spécifier qu'un minuteur d'inactivité est implémenté par le fournisseur pour cet affichage. En cas d'inactivité, cette fonctionnalité modifie le taux de rafraîchissement à un paramètre inférieur pour préserver l'énergie. La plate-forme utilisesetIdleTimerEnabled
pour contrôler le délai d'expiration du minuteur et, dans certains cas, pour le désactiver afin d'éviter des changements indésirables de taux de rafraîchissement en cas d'inactivité.L'utilisation du rappel
IComposerCallback.onVsyncIdle
indique à la plate-forme que l'affichage est inactif et que la cadencevsync
a changé. La plateforme répond à ce rappel en réinitialisant son modèlevsync
. Il force une resynchronisationvsync
sur l'image suivante et apprend la nouvelle cadencevsync
.
Mise en œuvre
Les fournisseurs ne sont pas tenus d’implémenter AIDL HAL pour Android 13. Cependant, ils sont encouragés à implémenter AIDL composer HAL au lieu de la version HIDL pour utiliser les nouvelles fonctionnalités et API.
Une implémentation de référence pour AIDL HWC HAL est implémentée dans les émulateurs Android.
Essai
Pour tester votre implémentation, exécutez VtsHalGraphicsComposer3_TargetTest
.