Audio Bluetooth à basse consommation

L'audio Bluetooth à faible consommation d'énergie (LEA) permet aux utilisateurs de recevoir 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 la prise en charge intégrée de LEA.

La plupart des casques LE Audio seront en mode dual jusqu'à ce que la part de marché des appareils sources LE Audio augmente. Les utilisateurs doivent pouvoir associer et configurer les deux modes de transport sur leurs casques dual mode.

Cas d'utilisation

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

• Partage audio: les utilisateurs peuvent partager simultanément plusieurs flux audio avec un ou plusieurs appareils récepteurs audio. Le son est synchronisé entre l'appareil source et les appareils connectés.

• Diffusion audio: les utilisateurs peuvent diffuser du contenu audio auprès de leurs amis et de leur famille, tout en se connectant à des diffusions publiques pour obtenir des informations, se divertir ou améliorer l'accessibilité.

• Compatibilité avec le codec audio LC3: il s'agit du codec audio par défaut. Il remplace le codec SBC utilisé pour A2DP (multimédia) et mSBC dans HFP (voix). 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 lorsqu'ils utilisent des micros. Le Bluetooth classique réduit la qualité audio lorsque vous utilisez des micros Bluetooth. Avec l'audio BLE, l'échantillonnage d'entrée et de sortie peut atteindre 32 kHz.

• Micro stéréo: les appareils auditifs peuvent enregistrer du son avec des micros stéréo pour améliorer le son spatial.

• Compatibilité avec le profil HAP (Hearing Aid Profile) : le profil HAP offre aux utilisateurs une accessibilité et une utilisation supérieures aux protocoles ASHA précédents. Les utilisateurs peuvent utiliser leurs prothèses auditives pour les appels téléphoniques et les applications VoIP.

• Compatibilité avec le protocole EATT (Enhanced Attribute Protocol) : EATT permet aux développeurs d'envoyer plusieurs commandes à la fois aux écouteurs associés.

Scénarios clés

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

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

2. Jeux: la lecture simultanée du micro et de la haute fidélité permet aux jeux de diffuser du contenu audio de haute qualité sur les écouteurs. Une application de jeu peut accéder à l'entrée audio BLE lorsqu'un jeu active le micro Bluetooth comme étant prêt à l'emploi. Ensuite, lorsqu'un joueur entame une conversation en direct avec un pair, l'application de jeu peut utiliser les données du micro immédiatement.

3. Multimédia: les applications multimédias sont autorisées à définir l'appareil préféré du gestionnaire audio. L'utilisateur peut ignorer cette valeur en modifiant l'appareil de son choix dans les paramètres du système.

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

API et méthodes audio BLE

Les API et méthodes suivantes sont requises pour prendre en charge les écouteurs 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 InCallService.setAudioRoute() et InCallService.requestBluetoothAudio() obsolètes, afin de 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. Le nouveau point de terminaison doit plutôt être l'un des points de terminaison valides fournis par InCallService.onAvailableCallEndpointsChanged(java.util.List).
• CallEndpoint.TYPE_BLUETOOTH dirige le flux audio via Bluetooth.
• Ces API InCallService mentionnées ci-dessus sont conçues pour être utilisées par l'application téléphonique par défaut sur un téléphone Android ou d'autres surfaces d'appel telles que les accessoires connectés, les automobiles ou d'autres appareils Bluetooth qui peuvent vouloir influencer le routage audio.

Telecom CallControl

• La nouvelle classe CallControl est introduite au 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 Connection.requestBluetoothAudio() et Connection.setAudioRoute(), qui sont obsolètes.
• En plus des API de la plate-forme Telecom mises à jour, la bibliothèque Jetpack Telecom est vivement recommandée lors de la création d'applications d'appels vocaux et/ou vidéo. Cette bibliothèque peut grandement simplifier 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. Permet de déterminer si l'appareil auditif est un appareil LEA.

Enregistreur audio

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

Adaptateur Bluetooth

• isLeAudioSupported() est renvoyé si le matériel de la plate-forme est compatible avec le LEA.
• isLeAudioBroadcastSourceSupported() renvoie si le matériel de la plate-forme est compatible avec LEA.

Guides en fonction du cas d'utilisation

Vous trouverez ci-dessous des consignes pour implémenter le 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 gère le routage audio et la logique d'état à votre place.

• Autogéré: pour les applications qui utilisent actuellement startBluetoothSco(), stopBluetoothSco() et setSpeakerphoneOn(), ou qui souhaitent gérer elles-mêmes l'état du routage audio, suivez le guide des appels autogérés Audio Manager.

• Gérées: utilisez la bibliothèque Telecom Jetpack ou les API de la 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 basculer entre les appareils Bluetooth. Pour en savoir plus, consultez le guide des appels gérés par les télécoms.

Applications d'enregistrement audio

• Enregistreur multimédia: lorsque vous effectuez un enregistrement audio avec Media Recorder, vous pouvez désormais enregistrer en stéréo si l'élément auditable Bluetooth est compatible avec la technologie LEA. Consultez le guide d'enregistrement audio.

Recommandations concernant les casques LE Audio (LEA)

À mesure que de plus en plus de casques LEA sont commercialisés, nous avons découvert des problèmes lors des tests réels qui dégradent l'expérience utilisateur. La spécification ne couvre pas tous ces problèmes. Le tableau suivant présente une liste de recommandations que les fabricants de casques LEA doivent suivre pour améliorer l'expérience de bout en bout des utilisateurs Android.

Description	Contexte
Prise en charge de la dérivation de clé de transport croisé (CTKD) pour les casques dual-mode : Prise en charge de la dérivation de clé pour l'association classique/LE et l'association LE-à-Classic.	La plupart des nouveaux casques LEA seront en mode double jusqu'à ce que la part de marché des appareils sources LEA augmente. Il est important que les utilisateurs puissent associer leurs casques dual-mode de manière fluide et configurer les deux modes de transport. Cela est également important pour l'Association express de Google.
Prenez en charge les annonces ciblées si vous souhaitez que vos casques 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é à la prochaine version du BT SIG.	Contrairement au modèle de paging BR/EDR, où une connexion peut être lancée par le téléphone ou le casque, une connexion dans LEA doit être lancée par l'appareil central. Actuellement, de nombreux casques n'utilisent pas de TA, ce qui signifie que l'appareil central risque de ne pas pouvoir se reconnecter au périphérique sans l'ajouter à une liste d'autorisation. Toutefois, une solution de contournement de la liste d'autorisation peut empêcher le casque de se connecter à un autre appareil central. Il est donc important que les casques LEA soient compatibles avec les TA afin que l'appareil central puisse se reconnecter de manière fiable sans solutions de contournement susceptibles de rompre les connexions multipoints.
Amélioration de la visibilité des écouteurs à double mode Le casque principal - composant BR/EDR doit diffuser des annonces à l'aide de son adresse publique et activer la requête et l'analyse de page avec son nom disponible via l'EIR, et définir le bit audio LE 14 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 sur une catégorie d'apparence appropriée correspondant au type d'appareil distant, en supposant que l'appareil central utilisera ces informations pour ajuster son UI 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 sur une catégorie d'apparence appropriée correspondant au type d'appareil distant, en supposant que l'appareil central utilisera ces informations pour ajuster son UI et ses règles de routage audio. Les écouteurs doivent élire dynamiquement un leader du groupe CSIP comme appareil principal. Si les écouteurs sont en mode double, l'appareil principal doit également être en mode double pour que les fonctionnalités LE et Classic fonctionnent correctement après l'association.	Cela évite que les écouteurs LEA dual-mode ne s'affichent en double dans les paramètres Bluetooth, ce qui pourrait prêter à confusion et compromettre l'expérience d'association LEA. L'élection dynamique du leader est particulièrement importante pour les appareils dual-mode associés de manière incrémentielle. Par exemple, si un seul écouteur est disponible lors de l'association initiale, il doit se présenter comme un appareil à double mode. Lorsqu'un utilisateur effectue l'association avec le deuxième écouteur plus tard, il ne doit s'associer qu'avec le composant LE, et le 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é.
Prise en charge du protocole EATT (Enhanced Attribute Protocol).	Réduit la latence d'appairage et de connexion.
Prise en charge de la mise en cache GATT robuste.	Réduit la latence de connexion, en particulier pour les écouteurs TWS.
Prenez en charge le sous-classement des connexions.	Permet une planification des paquets plus flexible et des économies de batterie potentielles.
Assurez-vous que, lors du pré- et post-traitement pour la lecture et la capture, le pipeline de traitement du signal peut fonctionner à 16, 24, 32 et 48 kHz, et qu'il prend en charge des fréquences plus élevées.	Exploite les taux d'échantillonnage plus élevés compatibles avec les chemins de capture d'appel LEA ou VoIP et la lecture multimédia.
Compatibilité avec le contrôle de l'alimentation LE	Meilleure gestion de l'alimentation

Compatibilité avec le type de contexte

Description	Contexte
Utilisez tous les types de contextes spécifiés dans Assigned Numbers 6.12.3, sauf si le casque n'est pas explicitement compatible avec un type de contexte donné.	Par exemple, si le type de contexte "Jeu" n'est pas compatible, Android envoie des sons de jeu. En particulier, notez que le type de contexte "Non spécifié" ne signifie pas "tout type de contexte" et ne couvre pas les types de contexte non compatibles.
Lorsque l'appareil central interagit avec l'ASCS du périphérique, celui-ci doit se connecter au MCS et au SGBS de l'appareil central. L'appareil central n'utilise pas toujours l'audio LE comme route de streaming, car il peut utiliser A2DP ou 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 inscription pour les notifications.