Audio Bluetooth à basse consommation

L'audio Bluetooth Low Energy (LEA) permet aux utilisateurs de bénéficier d'un son haute fidélité sans sacrifier l'autonomie de la batterie et de passer facilement d'un cas d'utilisation à un autre. Android 13 (niveau d'API 33) inclut une prise en charge intégrée de l'audio LEA.

La plupart des casques LEA seront bimodes jusqu'à ce que la part de marché des appareils sources LEA augmente. Les utilisateurs devraient pouvoir associer et configurer les deux transports sur leurs casques bimodes.

Cas d'utilisation

Vous pouvez intégrer l'audio LEA pour les cas d'utilisation suivants :

• Partage audio : les utilisateurs peuvent partager simultanément plusieurs flux audio sur un ou plusieurs appareils de destination audio. L'audio est synchronisé entre l'appareil source et les appareils connectés.

• Diffusion audio : les utilisateurs peuvent diffuser de l'audio à leurs amis et à leur famille, tout en se connectant à des diffusions publiques pour obtenir des informations, se divertir ou bénéficier d'une accessibilité.

• Prise en charge du codec audio LC3 : il s'agit du codec audio par défaut, qui remplace le codec SBC utilisé pour A2DP (média) et mSBC dans HFP (voix). Le codec LC3 est plus efficace, reconfigurable et de meilleure qualité.

• Améliorations de l'échantillonnage audio : les casques peuvent maintenir une qualité audio de sortie élevée lors de l'utilisation de microphones. Le Bluetooth classique réduit la qualité audio lors de l'utilisation de microphones Bluetooth. Avec l'audio BLE, l'échantillonnage d'entrée et de sortie peut atteindre 32 kHz.

• Microphone stéréo : les appareils auditifs peuvent enregistrer de l'audio avec des microphones stéréo pour améliorer le son spatial.

• Prise en charge du profil HAP (Hearing Aid Profile) : le profil HAP offre aux utilisateurs une accessibilité et une utilisation supérieures à celles des protocoles ASHA précédents. Les utilisateurs peuvent utiliser leurs appareils auditifs pour les appels téléphoniques et les applications VoIP.

• Prise en charge du protocole EATT (Enhanced Attribute Protocol) : le protocole EATT permet aux développeurs d'envoyer plusieurs commandes à la fois aux appareils auditifs associés.

Scénarios clés

Il existe quatre catégories principales de cas d'utilisation :

1. Conversationnel : les applications de numérotation et VoIP qui nécessitent un routage de communication à faible latence offrent un son de haute qualité et une consommation de batterie réduite.

2. Gaming : la lecture simultanée du microphone et de la haute fidélité permet aux jeux de diffuser de l'audio de haute qualité vers les appareils auditifs. Une application de jeu peut accéder à l'entrée audio BLE lorsqu'un jeu arme le microphone Bluetooth comme étant prêt à l'emploi. Ensuite, lorsqu'un joueur démarre une conversation en direct avec un autre joueur, l'application de jeu peut utiliser les données du microphone sans délai.

3. Média : les applications multimédias sont autorisées à définir l'appareil par défaut du gestionnaire audio. L'utilisateur peut remplacer ce paramètre en modifiant son appareil par défaut dans les paramètres du système.

4. Accessibilité : les appareils auditifs compatibles avec l'audio BLE peuvent désormais utiliser le microphone, ce qui permet aux utilisateurs de les utiliser en continu pour un appel.

API et méthodes audio BLE

Les API et méthodes suivantes sont nécessaires pour prendre en charge les appareils auditifs audio BLE :

AudioManager

• setCommunicationDevice() sélectionne l'appareil audio à utiliser pour les cas d'utilisation de communication, par exemple les appels vocaux ou vidéo. Cette méthode peut être utilisée par les applications de chat vocal ou vidéo pour sélectionner un autre appareil audio que celui sélectionné par défaut par la plate-forme. Cette API remplace les API obsolètes suivantes : startBluetoothSco(), stopBluetoothSco(), et setSpeakerphoneOn().
• clearCommunicationDevice() est appelé une fois que votre application a terminé un appel ou une session pour garantir une expérience utilisateur optimale lors du passage d'une application à une autre.

BluetoothProfile

• BluetoothLeAudio contrôle le service Bluetooth via un objet proxy.

Telecom InCallService

• InCallService#requestCallEndpointChange() remplace les API obsolètes InCallService.setAudioRoute() et InCallService.requestBluetoothAudio() pour permettre aux applications de demander le routage audio vers un CallEndpoint spécifique. Les clients ne doivent pas définir leur propre CallEndpoint lorsqu'ils demandent une modification. Au lieu de cela, le nouveau point de terminaison doit être l'un des points de terminaison valides fournis par InCallService.onAvailableCallEndpointsChanged(java.util.List).
• CallEndpoint.TYPE_BLUETOOTH dirige le flux audio via Bluetooth.
• Les API InCallService susmentionnées sont conçues pour être utilisées par l'application Téléphone par défaut sur un téléphone Android ou d'autres surfaces d'appel telles que les objets connectés, les automobiles ou d'autres appareils Bluetooth qui peuvent influencer le routage audio.

Telecom CallControl

• La nouvelle classe CallControl est introduite dans le niveau d'API 34 pour remplacer Connection et ConnectionService pour les applications VoIP uniquement.
• CallControl.requestCallEndpointChange() demande également une modification de CallEndpoint. Cette API remplace les API obsolètes Connection.requestBluetoothAudio() et Connection.setAudioRoute().
• Outre les API de plate-forme Telecom mises à jour, la bibliothèque Telecom Jetpack est fortement recommandée lors de la création d'applications d'appel vocal et/ou vidéo. Cette bibliothèque peut simplifier considérablement le processus d'intégration et améliorer les appels VoIP sur toutes les surfaces Android.

Informations sur l'appareil audio

• AudioDeviceInfo.TYPE_BLE_HEADSET décrit le type d'appareil audio comme un appareil LEA. Utilisé pour identifier si l'appareil auditif est un appareil LEA.

Enregistreur audio

• setPreferredDevice() définit l'appareil par défaut à utiliser pour le routage audio. L'utilisateur peut remplacer ce paramètre dans les paramètres système.

Adaptateur Bluetooth

• isLeAudioSupported() : renvoie une @BluetoothStatusCodes constante (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED, ou un code d'erreur) indiquant si le matériel de l'appareil est compatible avec l'audio LE.
• isLeAudioBroadcastSourceSupported() : renvoie une @BluetoothStatusCodes constante (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED ou un code d'erreur) indiquant si le matériel de l'appareil est compatible avec la source de diffusion audio LE.

Guides basés sur les cas d'utilisation

Vous trouverez ci-dessous des consignes pour implémenter l'audio LEA en fonction de cas d'utilisation spécifiques.

Applications de communication vocale

Les applications de communication vocale ont le choix de gérer le routage audio et l'état de l'appareil en gérant elles-mêmes leur état ou en utilisant l'API Telecom, qui effectue le routage audio et la logique d'état pour vous.

• Autogéré : pour les applications qui utilisent actuellement startBluetoothSco(), stopBluetoothSco(), et setSpeakerphoneOn() ou qui souhaitent autogérer l'état du routage audio, suivez le guide d'appel autogéré du gestionnaire audio.

• Géré : utilisez la bibliothèque Telecom Jetpack ou les API de plate-forme Telecom pour créer une application d'appel audio ou vidéo.

Ces deux solutions vous permettent de contrôler rapidement et facilement le routage audio et de passer d'un appareil Bluetooth à un autre. Pour en savoir plus, consultez le guide des appels gérés par Telecom.

Applications d'enregistrement audio

• Media Recorder : lorsque vous enregistrez de l'audio à l'aide de Media Recorder, vous pouvez désormais enregistrer en stéréo si l'appareil auditif Bluetooth est compatible avec l'audio LEA. Consultez le guide d'enregistrement audio.

Recommandations concernant les casques audio LEA

À mesure que de nouveaux casques audio LEA sont mis sur le marché, nous avons découvert des problèmes lors de tests en conditions réelles qui dégradent l'expérience utilisateur. La spécification ne couvre pas tous ces problèmes. Le tableau suivant fournit une liste de recommandations que les fabricants de casques audio LEA doivent suivre pour améliorer l'expérience de bout en bout des utilisateurs Android.

Description	Contexte
Prenez en charge la dérivation de clé de transport croisée (CTKD) pour les casques bimodes : Prenez en charge la dérivation de clé pour l'association Classic-to-LE et l'association LE-to-Classic.	La plupart des nouveaux casques audio LEA seront bimodes jusqu'à ce que la part de marché des appareils sources LEA augmente. Il est important que les utilisateurs puissent associer leurs casques bimodes de manière transparente et configurer les deux transports. Cela est également important pour Google Fast Pair.
Prenez en charge les annonces ciblées (TA) si vous souhaitez que vos casques audio LEA se reconnectent de manière fiable aux appareils sources. Les écouteurs audio LE doivent utiliser des TA pour demander une connexion entrante à partir des appareils centraux. Sera ajouté au prochain BT SIG.	Contrairement au modèle de radiomessagerie BR/EDR, où une connexion peut être initiée par le téléphone ou le casque, une connexion dans LEA doit être initiée par l'appareil central. Actuellement, de nombreux casques n'utilisent pas de TA, ce qui signifie que l'appareil central peut ne pas être en mesure de se reconnecter au périphérique sans l'ajouter à une liste d'autorisation. Toutefois, une solution de contournement de liste d'autorisation peut empêcher le casque de se connecter à un autre appareil central. Par conséquent, il est important que les casques audio LEA prennent correctement en charge les TA afin que l'appareil central puisse se reconnecter de manière fiable sans solutions de contournement susceptibles d'interrompre les connexions multipoints.
Découvrabilité optimisée pour les écouteurs bimodes L'écouteur principal (composant BR/EDR) doit diffuser des annonces à l'aide de son adresse publique, activer la requête et l'analyse de page avec son nom disponible via EIR, et définir le bit 14 de l'audio LE sur 1 dans les classes de service principales de la classe d'appareil (CoD). Écouteur principal (composant LE) : l'écouteur principal doit effectuer une annonce connectable et détectable (limitée ou générale) à l'aide de la même adresse publique que le composant BR/EDR et du même nom local complet que le composant BR/EDR, avec sa catégorie d'apparence définie comme une catégorie d'apparence appropriée correspondant au type d'appareil distant, en s'attendant à ce que l'appareil central utilise ces informations pour ajuster son interface utilisateur et ses règles de routage audio. Écouteur secondaire (LE uniquement) : l'écouteur secondaire doit effectuer une annonce connectable et non détectable avec sa catégorie d'apparence définie comme une catégorie d'apparence appropriée correspondant au type d'appareil distant, en s'attendant à ce que l' appareil central utilise ces informations pour ajuster son interface utilisateur et ses règles de routage audio. Les écouteurs doivent élire dynamiquement un leader du groupe CSIP comme appareil principal. Si l'écouteur est bimode, l' appareil principal doit être bimode pour s'assurer que les fonctionnalités LE et Classic fonctionnent correctement après l'association.	Cela empêche les écouteurs LEA bimodes d'apparaître comme des entrées en double dans les paramètres Bluetooth, ce qui pourrait dérouter les utilisateurs et compromettre l'expérience d'association LEA. L'élection dynamique du leader est particulièrement importante pour les appareils bimodes associés de manière incrémentale. Par exemple, si un seul écouteur est disponible lors de l'association initiale, il doit se présenter comme un appareil bimode. Lorsqu'un utilisateur associe le deuxième écouteur ultérieurement, il n'a besoin de l'associer qu'au composant LE, et CSIP s'assurera qu'ils sont regroupés sur Android. L'adresse d'identité est recommandée lors de l'association, car le composant BR/EDR expose déjà l'adresse publique de l'appareil aux appareils à proximité.
Prenez en charge le protocole EATT (Enhanced Attribute Protocol).	Réduit la latence d'association et de connexion.
Prenez en charge la mise en cache GATT robuste.	Réduit la latence de connexion, en particulier pour les écouteurs TWS.
Prenez en charge la sous-évaluation de la connexion.	Permet une planification des paquets plus flexible et des économies de batterie potentielles.
Assurez-vous que, lors du prétraitement et du post-traitement pour la lecture et la capture, le pipeline de traitement du signal peut fonctionner à 16, 24, 32 et 48 kHz, et prendre en charge des fréquences plus élevées.	Tire parti des taux d'échantillonnage plus élevés pris en charge pour les chemins de capture d'appel ou VoIP LEA et la lecture multimédia.
Prenez en charge le contrôle de l'alimentation LE.	Meilleure gestion de l'alimentation

Prise en charge du type de contexte

Description	Contexte
Utilisez tous les types de contexte spécifiés dans les numéros attribués 6.12.3 , sauf si le casque ne prend pas explicitement en charge un type de contexte donné.	Par exemple, si le type de contexte "Jeu" n'est pas pris en charge, Android enverra des sons de jeu. Notez en particulier que le type de contexte "Non spécifié" ne signifie pas "n'importe quel type de contexte" et ne couvre pas les types de contexte non compatibles.
Lorsque l'appareil central interagit avec l'ASCS de l'appareil périphérique, le périphérique doit se connecter au MCS et au TBS de l'appareil central. L'appareil central peut ne pas toujours utiliser l'audio LE comme route de streaming car il peut revenir à l'utilisation d'A2DP ou de HFP. L'appareil périphérique peut utiliser l'interaction ASCS pour indiquer si l'appareil central utilisera l'audio LE pour le streaming. Voici quelques exemples d'interactions ASCS : lecture, écriture et enregistrement pour notification.