Cette page explique comment activer le framework audio et l'AHAL (Audio HAL) pour gérer les connexions SCO (Synchronous Connection-Oriented), un processus appelé AMSCO (Audio Managed SCO).
Dans Android 17 et versions ultérieures, le framework audio Android utilise la fonctionnalité de gestion SCO pour gérer le routage SCO, qui était initialement géré par le framework Bluetooth (BT). Cette migration fait passer l'état de la connexion SCO d'un état appartenant au framework BT à une conséquence en aval de l'activité de streaming audio.
En centralisant la propriété du routage audio dans le framework audio, cette fonctionnalité aligne l'implémentation de la couche d'abstraction matérielle audio (HAL) pour SCO avec d'autres profils BT tels que le profil de distribution audio avancé (A2DP) et LE Audio. Cette refactorisation simplifie l'interaction entre les piles télécom et BT, ce qui permet d'obtenir une architecture de routage audio plus robuste et centralisée.
Présentation de l'architecture
L'architecture AMSCO centralise la gestion des connexions SCO dans le framework audio Android, qui base les décisions de routage sur l'activité de streaming audio. Cette architecture contraste avec le modèle précédent, dans lequel la pile BT gérait les connexions. Voici le rôle de chaque composant de cette architecture :
L'AHAL démarre et suspend la session SCO uniquement si les conditions suivantes sont remplies :
- Un flux actif est associé à un appareil SCO.
- Le mode audio est défini et un correctif pour un appareil SCO existe.
Le framework audio empêche un appareil A2DP d'avoir un correctif simultané lorsque ces critères spécifiques sont remplis. Le framework audio n'envoie plus les changements d'état SCO ni les suspensions A2DP à l'AHAL.
Le framework audio gère la gestion SCO. La pile BT n'appelle donc plus la connexion ou la déconnexion audio. En cas d'erreur ou de déconnexion SCO préventive, la pile BT informe le framework audio avec AudioManager#onHfpAudioDisconnected.
Plan
Utilisez les informations de cette section pour évaluer les exigences de compatibilité et d'architecture suivantes avant d'implémenter la refactorisation de la gestion des SCO.
Rétrocompatibilité.
Pour permettre au framework de continuer à prendre en charge les appareils susceptibles de recevoir des mises à jour de l'OS sans mettre à jour leurs AHAL ou AHAL BT, utilisez une propriété système pour indiquer que la nouvelle gestion SCO doit être activée. L'ancien chemin est conservé pendant six ans maximum lorsque la propriété système est désactivée ou que la version HAL est obsolète.
Configurer la session HFP
L'AHAL doit utiliser le nouveau type de session HFP (Hands-Free Profile) pour démarrer ou suspendre la lecture, comme les autres types de sessions BT. L'état du flux est finalement géré à l'aide de différents IBluetoothAudioProviders, qui sont énumérés et créés par une classe Factory en fonction des chemins d'accès disponibles.
La pile BT utilise un chemin de déchargement matériel chaque fois que cela est possible. La préférence pour les codecs lors de la négociation suit cet ordre : le codec LC3 matériel est préféré au codec LC3 logiciel, suivi du codec mSBC matériel, puis du codec mSBC logiciel, et enfin le codec CVSD matériel est préféré au codec CVSD logiciel.
Les schémas de séquence suivants détaillent les interactions entre l'AHAL et la pile BT requises pour établir l'état du flux.
Procédure de déchargement matériel
La figure 1 montre comment la couche AHAL et la pile Bluetooth se coordonnent pour établir un chemin de données matérielles direct pour l'audio SCO :
Figure 1. Procédure de déchargement matériel.
Procédure de chemin d'accès aux données logicielles
La figure 2 illustre le processus de traitement des données audio qui nécessite un traitement par le logiciel système :
Figure 2. Procédure de chemin d'accès aux données logicielles.
Procédure de renégociation du codec
Lorsque la passerelle audio (AG) reçoit une nouvelle commande de codec BT disponible (AT+BAC), elle redémarre la procédure de négociation du codec. La figure 3 illustre la procédure de renégociation du codec :
Figure 3. Procédure de renégociation du codec.
Impact sur HeadsetStateMachine
La machine à états du casque de la couche Java (représentée par la classe HeadsetStateMachine) reste en grande partie inchangée, à l'exception de l'état AUDIO_CONNECTED, qui est piloté par des événements de pile native.
Dans la couche Java, le système n'initie plus connectAudioNative ni disconnectAudioNative. Au lieu de cela, le système répond aux changements d'état de la connexion audio à partir de la pile native. Ces modifications sont déclenchées par les commandes de l'AHAL sur IBluetoothAudioProvider ou IBluetoothAudioPort.
Implémentation
Pour intégrer la refactorisation de la gestion SCO, mettez à jour la communication entre la pile BT et le framework audio.
Pour implémenter la fonctionnalité, procédez comme suit :
Informer le framework audio des modifications apportées au BT actif pour faciliter la gestion appropriée de l'initialisation et de l'arrêt de SCO lors des connexions d'appareils HFP et pour gérer les changements d'appareils actifs. Utilisez
AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo)pour fournir ces informations au framework audio.
Figure 4. Connectez l'appareil HFP.
Le framework audio utilise le rappel
AudioManagerAudioDeviceCallback#onAudioDevicesAddedau lieu des diffusions héritées pour indiquer l'état de l'appareil audio.Implémentez le contrôle du flux AHAL à l'aide de
setCommunicationDevice(AudioDeviceInfodevice)comme point de contrôle principal pour démarrer la connexion SCO.Si
HfpTransport::StartRequestrenvoieBluetoothAudioCtrlAck::PENDING, l'AHAL doit relancer la requête, car la machine à états HFP n'est pas établie.
Cas d'utilisation
Les sections suivantes décrivent les parcours utilisateur critiques (CUJ) types.
Flux d'appel télécom
La refactorisation de la gestion SCO transforme phoneStateChanged en fonction de blocage. Cette modification permet à l'application de télécommunications d'attendre la fin de l'exécution de phoneStateChanged dans la méthode BluetoothInCallService.onCallAdded() avant d'appeler l'API du framework audio pour démarrer la création de SCO.
Figure 5. Répondez à un appel ou passez-en un via l'opérateur télécom.
Flux d'appel VoIP
Le framework audio lance le processus en appelant la méthode BluetoothHeadset.startScoUsingVirtualVoiceCall. Une fois que la pile BT fournit un résultat au framework audio, celui-ci demande à l'AHAL d'exécuter startStream. La figure suivante illustre ce flux :
Figure 6. Répondez à un appel ou passez-en un via la VoIP.
Reconnaissance vocale
Pour la reconnaissance vocale initiée par l'AG et en mains libres (HF), la pile BT doit demander au framework audio d'ouvrir SCO à l'aide de AudioManager.setCommunicationDevice(). Ce processus est illustré dans la figure suivante :
Figure 7. Lancement de la reconnaissance vocale SCO.
Connexion audio
La pile BT lance une connexion SCO en demandant le framework audio avec AudioManager.setCommunicationDevice(AudioDeviceInfo) lors de la reconnaissance vocale. Si un appel est actif, la pile BT demande plutôt BluetoothInCallService#requestBluetoothAudio à la pile télécom.
Ce processus est illustré dans la figure suivante :
Figure 8. Connexion audio.
Validation et test
Pour vérifier que la fonctionnalité est correctement intégrée et qu'elle répond aux normes de qualité, les fabricants d'appareils doivent exécuter les tests suivants :
- CTS Verifier : utilisez CTS Verifier pour tester de manière interactive le routage audio pendant les appels.
- Vendor Test Suite (VTS) : validez les interactions AHAL et BT AHAL à l'aide de VTS.
Conditions requises
Cette fonctionnalité est soumise aux exigences suivantes :
- AHAL : l'implémentation nécessite un AHAL compatible qui accepte le chemin de gestion SCO refactorisé.