HAL audio HIDL

Sous Android 13 et versions antérieures, l'interface Audio HAL est définie à l'aide de HIDL dans les fichiers HIDL HAL (avec l'extension .hal ) et des schémas XSD pour les fichiers de configuration, illustrés comme suit.

audio_hal

Figure 1. Interface audio HAL.

Fichiers de configuration

Les fichiers de configuration XML de politique audio et d’effets audio sont considérés comme faisant partie de l’interface Audio HIDL HAL. Ces fichiers doivent être conformes à leurs schémas, et la conformité est vérifiée par des tests VTS.

Dans le cadre de la mise en œuvre de l'audio HIDL HAL, vous devez créer un fichier de configuration de stratégie audio qui décrit la topologie audio. Les fonctionnalités audio HAL doivent être déclarées dans le fichier audio_policy_configuration.xml pour que le framework puisse les utiliser.

API audio HIDL HAL

Cette section décrit les API HAL principales, d'effets et communes pour HIDL.

HAL de base

Certaines des interfaces clés de Core HAL, utilisant HIDL, sont les suivantes :

  • IDeviceFactory.hal est le point d'entrée dans l'API.
  • IDevice.hal et IPrimaryDevice.hal contiennent des méthodes telles que setMasterVolume ou openInputStream .
  • Les flux sont unidirectionnels et sont utilisés par AudioFlinger pour envoyer ou recevoir de l'audio vers et depuis le HAL via IStream.hal , IStreamOut.hal et IStreamIn.hal .

Le tableau suivant répertorie l'emplacement des composants Core HAL HIDL utiles :

Composant principal de HAL Emplacement
Dernière version de l'API /hardware/interfaces/audio/6.0
Types spécifiques à la dernière API Core HAL /hardware/interfaces/audio/6.0/types.hal
Schéma XSD du fichier de configuration de la stratégie audio /hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd

L'implémentation par défaut de l'API Core HAL ( /hardware/interfaces/audio/core/all-versions/default/ ) est un wrapper autour de l'implémentation pré-Treble HAL utilisant les bibliothèques partagées héritées . L'implémentation par défaut peut également être considérée comme une référence lors de l'implémentation de nouvelles versions de HAL audio qui interagissent directement avec les pilotes du noyau.

Effets HAL

Le tableau suivant répertorie l'emplacement des composants d'effets HAL utiles utilisant HIDL :

Composant Effets HAL Emplacement
Dernière version de l'API /hardware/interfaces/audio/effect/6.0/
Schéma XSD du fichier de configuration des effets /hardware/interfaces/audio/effect/6.0/xml/audio_effects_conf.xsd

Pour plus d'informations, consultez un exemple d'implémentation de l'API Effects HAL dans /hardware/interfaces/audio/effect/all-versions/default/ et la section Effets audio .

HAL commun

L'API Common HAL utilisant HIDL contient les éléments suivants :

  • Définitions ( /hardware/interfaces/audio/common/6.0/types.hal ) partagées par les API Core et Effect.
  • Utilitaires ( /hardware/interfaces/audio/common/all-versions ) utilisés pour faciliter le codage avec les API HIDL pour les implémentations, les clients et les tests.

Mises à jour de l'Audio HAL V7

Des changements importants ont été apportés à la version 7 de Audio HAL dans Android 12, comme indiqué dans cette section. L'Audio HAL V7 effectue les opérations suivantes :

  • Unifie les modèles de données utilisés par le framework et HAL.
  • Minimise la duplication entre les types de données HIDL (énumérations) et le schéma XML utilisé pour la configuration de la stratégie audio.

Plus précisément, des modifications sont apportées dans les domaines suivants dans Audio HAL V7 :

Ces changements sont discutés plus en détail dans leurs sections respectives.

Énumérations

À partir d'Audio HAL V7, les types énumérés utilisés dans le fichier de configuration de politique audio sont définis uniquement dans le schéma XSD et non dans HIDL.

Dans Audio HAL V6, les valeurs des types enum (comme AudioFormat ) dans types.hal sont également définies dans le schéma XSD du fichier de configuration de la politique audio, créant ainsi une duplication. Pour éviter cela dans la version V7, les types d'énumération sont remplacés par string et toutes les valeurs d'énumération possibles sont répertoriées dans le schéma XSD.

La figure 2 compare certaines des modifications apportées au type d'énumération AudioFormat dans la version V7 :

audioformat-change

Figure 2. Comparaison de certaines des modifications apportées à l'énumération AudioFormat.

Reportez-vous à la liste suivante pour les types d'énumération qui ont été convertis en string :

  • AudioChannelMask
  • AudioContentType
  • AudioDevice : fournisseur extensible
  • AudioFormat : Fournisseur extensible
  • AudioGainMode
  • AudioSource
  • AudioStreamType
  • AudioUsage

Transmettre les valeurs d'énumération de chaîne

Les valeurs de chaîne sont utilisées pour transférer des informations sous forme de valeurs d'énumération à travers la limite de l'interface HAL. Le framework et le wrapper HAL utilisent tous deux des valeurs d'énumération entières pour implémenter la logique métier et emploient l'approche de conversion décrite dans la figure 3 :

audio-passing-values

Figure 3. Passage de valeurs d'énumération de chaîne.

A titre d'exemple, pour transmettre une valeur de type format audio du framework au fournisseur :

  1. La valeur enum de AudioFormat est convertie en valeur de chaîne dans libaudiohal et est transmise au HAL.
  2. Du côté de HAL, le wrapper par défaut convertit la chaîne en une valeur enum, qui est transmise à l'ancien HAL.

Modifications du schéma XML

Le fait de disposer de listes complètes de valeurs d'énumération dans la définition de schéma XML (XSD) permet une meilleure validation des fichiers XML de configuration de la politique audio par VTS. Nous avons apporté des modifications au fichier de configuration de la politique audio utilisé avec HAL V7 pour se conformer à XSD.

Dans la version V7, un caractère standard ␣ (espace) est utilisé pour délimiter les listes de valeurs dans les attributs (comme les taux d'échantillonnage, les masques de canal et les indicateurs), au lieu des caractères , (virgule) et | (barre verticale) symboles utilisés dans V6 et versions antérieures. Comme le montre l'exemple suivant, un espace est utilisé pour délimiter la liste de valeurs pour channelMasks :

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Pour apporter les modifications aux symboles, utilisez un script de conversion automatique appelé update_audio_policy_config.sh . Consultez la commande suivante pour convertir un fichier de configuration de stratégie audio V6 en une version V7 pour l'appareil Pixel 5 (Redfin) :

hardware/interfaces/audio/7.0/config/update_audio_policy_config.sh \
device/google/redfin/audio/audio_policy_configuration.xml 6.0

Types de données

Nous avons redéfini certaines structures de données dans la V7 pour minimiser les définitions en double. Les tuples répétés d'éléments de données sont regroupés dans des structures réutilisables. Ces structures de données utilisent les dernières fonctionnalités HIDL telles que les unions sécurisées.

Par exemple, dans la version V6 et versions antérieures, un triplet <format, sampling rate, channel mask> est souvent utilisé dans les interfaces et types HIDL. Pour supprimer cette redondance, dans la V7, le type de données AudioConfigBase et les autres types de données sont définis comme suit :

  • AudioConfigBase := <format, sampling rate, channel mask>

  • AudioConfigBaseOptional := <[fmt], [sampl. rate], [chan. mask]>

    utilisé par AudioConfig , AudioOffloadInfo , AudioPortConfig

  • AudioProfile := <format, {sampling rates}, {channel masks}>

    remplace les collections lâches dans AudioPort/PortConfig

  • AudioPortExtendedInfo := device | mix | session

    remplace les unions dans AudioPort/PortConfig

Balises du fournisseur

En plus des types et formats d'appareils, les fournisseurs peuvent ajouter des balises personnalisées pour les métadonnées des pistes audio.

Pour les métadonnées des pistes de lecture et d'enregistrement, les fournisseurs peuvent transmettre leurs propres balises, qui sont utilisées pour ajouter des attributs aux flux d'E/S audio, des applications vers HAL.

Les balises de fournisseur pour les métadonnées de la piste de lecture sont ajoutées comme le montre l'exemple suivant :

struct PlaybackTrackMetadata {
…
    /** Tags from AudioTrack audio attributes */
    vec<AudioTag> tags;
};

La structure RecordTrackMetadata est implémentée de la même manière en ajoutant des balises spécifiques aux métadonnées de la piste d'enregistrement.

Espace de noms des extensions de fournisseur

À partir de HAL V7, les extensions de fournisseur nécessitent un préfixe {vendor} supplémentaire qui n'est pas requis dans la version V6. Pour que le préfixe {vendor} soit valide, il doit contenir au moins trois caractères alphanumériques.

Utilisez le format suivant dans la V7 :

VX_{ vendor }_{ letters/numbers }

Voici quelques exemples d'extensions de fournisseur V7 valides :

  • VX_ GOOGLE _VR
  • VX_ QCI _AMBIENT_MIC

Information sur la version

Le tableau suivant répertorie le numéro de version HAL pour chaque version d'Android :

Version Android Version HIDL-HAL
Android 13 7.1
Android 12 7.0
Android 11 6.0
Android 10 5.0
Android 9 4.0
Android 8 2.0