AIDL pour Hardware Composer HAL

À 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 AIDL et le HAL HIDL pour le HWC, et la mise en œuvre et le test du HAL AIDL.

En raison des avantages offerts par AIDL, les fournisseurs sont encouragés à implémenter le HAL du compositeur AIDL à partir d'Android 13 au lieu de la version HIDL. Pour en savoir plus, consultez la section Implémentation.

Différences entre les HAL AIDL et HIDL

Le nouveau HAL du compositeur AIDL, nommé android.hardware.graphics.composer3, est défini dans IComposer.aidl. Il expose une API semblable à l'API HAL HIDL android.hardware.graphics.composer@2.4 avec les modifications suivantes :

  • Suppression de la file d'attente de messages rapide (FMQ) au profit des commandes parcelables.

    Le HAL AIDL définit l'interface de commande en fonction de types parcellables fortement typés, contrairement aux commandes sérialisées via 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 dans IComposerClient.aidl en tant que

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

    où chaque commande est un type parcelable fortement typé défini dans DisplayCommand.aidl. Les réponses aux commandes sont des parcelables fortement typés définis dans CommandResultPayload.aidl.

  • Suppression de IComposerClient.getClientTargetSupport, car il n'existe aucun client actif pour cette méthode.

  • Représentation des couleurs sous forme de nombres à virgule flottante au lieu d'octets pour mieux s'aligner sur la pile graphique supérieure d'Android, comme défini dans ASurfaceTransaction_setColor.

  • Ajout de nouveaux champs permettant de contrôler le contenu HDR.

    Dans le HAL d'AIDL, les piles de couches SDR/HDR mixtes prennent en charge l'assombrissement fluide des couches SDR lorsqu'une couche HDR s'affiche simultanément à l'écran.

    Le champ brightness dans LayerCommand permet à SurfaceFlinger de spécifier une luminosité par couche, de sorte que le HWC diminue la luminosité du contenu de la couche dans un espace lumineux linéaire, par opposition à l'espace gamma.

    Le champ brightness dans ClientTargetPropertyWithBrightness permet au HWC de spécifier l'espace de luminosité pour la composition client et d'indiquer à RenderEngine s'il faut assombrir les calques SDR dans la composition client.

    Le champ dimmingStage permet au HWC de configurer quand RenderEngine doit atténuer le contenu. Cela permet d'accepter les ColorModes 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 dans Composition.aidl pour les décorations d'écran.

    Certains appareils disposent de matériel dédié pour optimiser le dessin du masque alpha qui lisse les coins arrondis et les encoches sur les écrans. Les appareils dotés de ce matériel doivent implémenter IComposerClient.getDisplayDecorationSupport pour renvoyer une structure DisplayDecorationSupport telle que définie dans le nouveau DisplayDecorationSupport.aidl. Cette structure décrit les énumérations PixelFormat et AlphaInterpretation requises par l'appareil. Lors de cette implémentation, l'UI système marque la couche de masque alpha comme DISPLAY_DECORATION, un nouveau type de composition qui exploite le 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 s'afficher à l'écran. Grâce à cette fonctionnalité, SurfaceFlinger envoie à l'avance une commande de présentation à l'implémentation, ce qui lui permet de traiter 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 de BOOT_DISPLAY_CONFIG, les fournisseurs peuvent spécifier que la configuration d'affichage de démarrage est prise en charge. Les méthodes setBootDisplayConfig, clearBootDisplayConfig et getPreferredBootDisplayConfig utilisent BOOT_DISPLAY_CONFIG comme suit :

    • À l'aide de setBootDisplayConfig, le framework informe les fournisseurs de la configuration d'affichage au démarrage. Les fournisseurs doivent mettre en cache la configuration d'affichage de démarrage et démarrer dans cette configuration lors du prochain redémarrage. Si l'appareil ne parvient pas à démarrer dans cette configuration, le fournisseur doit trouver une configuration correspondant à la résolution et à la fréquence d'actualisation de cette configuration. Si aucune configuration de ce type n'existe, le fournisseur doit utiliser la configuration d'affichage de son choix.

    • À l'aide de clearBootDisplayConfig, le framework demande aux fournisseurs d'effacer la configuration de l'affichage de démarrage et de démarrer avec la configuration d'affichage préférée au 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 compatible, ces méthodes renvoient la valeur UNSUPPORTED.

  • Ajout de nouvelles API pour contrôler le minuteur d'inactivité de l'écran.

    • À l'aide de DISPLAY_IDLE_TIMER, les fournisseurs peuvent spécifier qu'ils doivent implémenter un minuteur d'inactivité pour cet affichage. Lorsque l'appareil est inactif, cette fonctionnalité définit la fréquence d'actualisation sur un paramètre inférieur pour économiser de l'énergie. La plate-forme utilise setIdleTimerEnabled pour contrôler le délai avant expiration du minuteur et, dans certains cas, pour le désactiver afin d'éviter les changements de fréquence d'actualisation indésirables en cas d'inactivité.

    • L'utilisation du rappel IComposerCallback.onVsyncIdle indique à la plate-forme que l'écran est inactif et que la cadence vsync a changé. La plate-forme répond à ce rappel en réinitialisant son modèle vsync. Il force une resynchronisation de vsync sur le frame suivant et apprend la nouvelle cadence vsync.

Implémentation

Les fournisseurs ne sont pas tenus d'implémenter la solution AIDL HAL pour Android 13. Toutefois, nous les encourageons à implémenter le HAL du compilateur AIDL au lieu de la version HIDL pour utiliser les nouvelles fonctionnalités et API.

Une implémentation de référence pour le HAL du matériel AIDL est implémentée dans les émulateurs Android.

Tests

Pour tester votre implémentation, exécutez VtsHalGraphicsComposer3_TargetTest.