Comment modifier la pile Bluetooth d'Android pour activer le récepteur A2dp
Je travaille sur une application d'enregistrement audio qui utilise un micro Bluetooth pour enregistrer de l'audio sur un appareil Android (Nexus 7 - enraciné Android 4.4.2) Il est actuellement implémenté sur HFP et tout fonctionne bien. Le micro Bluetooth est implémenté avec le module Bluetooth WT32 de Bluegiga + une entrée micro, la qualité audio via HFP n'est pas excellente mais elle est suffisante pour le moment.
Cependant, j'essaie maintenant de changer le profil Bluetooth en A2dp, car il y a deux entrées micro (L/R) et WT32 prend en charge A2dp (source). Après de nombreuses recherches, j'ai trouvé que le stock Android ne prend pas en charge A2dp (récepteur), et il est possible de modifier la pile Bluetooth d'Android pour activer A2dp (récepteur).
Ce que je ne comprends pas, c'est comment accéder et modifier la pile Bluetooth. Ce serait bien si quelqu'un avec une réponse était capable de décomposer les étapes pour y parvenir.
J'ai essayé de suivre la réponse à cette question: Recevoir de l'audio via Bluetooth dans Android , mais je n'arrive pas à trouver le fichier approprié à modifier. En fait, je ne sais même pas si je regarde dans le bon dossier. J'ai parcouru le fichier des appareils via l'explorateur de fichiers DDMS d'Android-studio.
ps, je suis encore assez nouveau avec Android développement d'applications, donc j'ai peut-être mal utilisé certaines terminologies et je m'en excuse à l'avance pour cela.
C'est en fait ce que j'essaie de faire depuis longtemps ... La raison pour laquelle vous ne pouvez pas trouver le fichier de configuration est que Google a remplacé la pile Bluetooth de BlueZ par une nouvelle pile construite par Google et Broadcom. La nouvelle pile utilise un fichier de configuration différent, avec lequel je ne sais pas comment bricoler.
Si vous êtes sérieux à ce sujet, la chose la plus proche que j'ai trouvée pour commencer est l'introduction officielle du cadre Bluetooth sur Android: https://source.Android.com/devices/bluetooth.html
La réponse ci-dessus n'est donc pas totalement correcte.
Voici comment il se décompose:
HAL, est la couche d'abstraction matérielle qui implémente les machines d'état Bluetooth réelles en code c/cpp, en tant que telle, elle contrôle les différentes machines d'état pour les services A2dp, HFP, GATT, SPP, AVRCP, etc. Chacun de ces services fait également référence aux fichiers SMP et ATT pour contrôler le serveur Bluetooth ou les bases de données client réelles, et leur sécurité.
HCI, c'est là que le travail se fait. le HAL n'a pas vraiment faire quoi que ce soit, il assemble les messages de données complexes qui sont envoyés le long d'une série tty (spi ou UART) à une puce connectée entre réseaux sur le PCBA via les méthodes utilisées dans la couche HCI, qui peut être trouvée dans la couche "BTE" dans le répertoire/external/bluetooth/bluedroid/d'un Android compiler le tronc d'AOSP 4.2.2 vers le courant. - actuellement il y a plusieurs fabricants de ces puces, mais ils sont pour la plupart tous des ic basés sur Broadcom emballés dans un package radio double ou triple qui contient une radio wifi, Bluetooth 4.0 Smart et Bluetooth 4.0.
Il est possible de faire ce que vous essayez de faire, mais vous devez inclure hardware.so et bluetooth_jni.so dans un package/projet NDK/JNI qui va avec vos applications et s'inscrire via les appels des fichiers .cpp pour chacun des services Bluetooth trouvés dans "Packages/apps/Bluetooth/jni", vous géreriez alors l'enregistrement dans votre bibliothèque NDK de "com_Android_bluetooth_a2dp.cpp" et "com_Android_bluetooth_avrcp.cpp", comme leurs objets correctement saisis.
L'autre problème est que vous devrez implémenter votre propre pile A2DP personnalisée, car la pile Android Bluedroid n'a que des bits et des morceaux du rôle Sink implémenté dans les frameworks tandis que le rôle A2DP a une implémentation complète du rôle Source. De plus, selon ce que vous avez réellement l'intention de faire avec votre implémentation de récepteur A2DP Bluetooth, vous devrez également implémenter AVRCP - conformément au Bluetooth SIG (spécial groupe d'intérêt), il existe des exigences d'interconnectivité entre les périphériques Bluetooth qui entraîneront des problèmes majeurs si vous implémentez le rôle de récepteur, sans AVRCP "périphérique cible de contrôle à distance" et "périphérique de contrôle de télécommande", comme le rôle de récepteur ATT commande à partir de Bluetooth sur A2DP (ou tout service/profil Bluetooth) exécute certaines poignées de main pendant le processus de découverte de service, lorsque la passerelle associée (le périphérique de connexion), exécute une demande de capacités, le service A2DP est censé implémenter des capacités d'E/S pour les commandes Start Stop, et po ignorer/suivre les commandes d'avance.
En plus de tout cela, lors de la mise en œuvre d'A2DP, vous devrez choisir si vous gérerez les flux PCM ou AAC. Si vous manipulez des flux AAC (ou des flux PCM protégés par DRM d'ailleurs, que quelque chose comme Pandora, spotify, etc. utilise), vous devez implémenter l'encodeur ou le décodeur SBC approprié à votre implémentation, sinon tout ce que vous aurez est un tas de données cryptées. Assurez-vous également d'implémenter le débit à la vitesse appropriée pour la mise en œuvre de votre appareil AudioManager, certains téléphones utilisent 48 000 Hz et certains 44 100 Hz, ce qui est important si vous voulez un son de haute qualité, comme la plupart des implémentations PCM A2DP qui utilisent Surround Sound 7.1 + nécessitera 48 000 Hz ainsi qu'un encodage/décodage AAC.
J'espère que cela vous donnera un aperçu.
https://Android-review.googlesource.com/#/c/98161/ implémente A2DP Sink. Cela fonctionne sur Nexus 5. Vous pouvez l'essayer.
De nombreux changements sont survenus dans Android OS au fil du temps.
À partir de Android O (Android 8. *), les profils de récepteur sont partiellement pris en charge par Google. Tels que le récepteur audio fonctionnera facilement s'il est activé dans le profil. Il semble que la couche supérieure de BT soit gentille d'implémentation complète au niveau du framework, qui se présente sous la forme d'App ie packages/app/Bluetooth (avec quelques bugs mais fonctionne toujours). Mais tous les profils ne sont pas complétés à la couche inférieure du framework via des interfaces HAL qui sont un framework btif (comme btif_rc.cpp, etc. que vous pouvez consulter Android) et qui remplace l'ancienne pile Bluez par Google.
Comme je l'ai dit, le récepteur BT est partiellement implémenté et est en cours de réalisation. Le récepteur BT tel que l'audio fonctionnera facilement s'il est activé en tant que profil récepteur, mais pas tous comme AVRCP ne fonctionnera pas. À l'heure actuelle, j'ai vu le problème avec le code AOSP que le trafic entrant de l'appareil distant vers Android fonctionne, mais le trafic sortant de Android vers l'appareil distant ne fonctionne pas fonctionne (sur lequel le profil AVRCP fonctionne) car l'objet d'appareil distant n'est pas conservé dans la pile et les appels JNI depuis app/Bluetooth échouent avec un appareil nul à btif_*.cpp des dossiers. Par exemple, envoyer des commandes directes ne fonctionne pas.
Ainsi, nous pouvons voir des profils de récepteur Bluetooth fonctionner à l'avenir.
Si vous voulez en savoir plus, consultez AOSP,
- Services à
packages/app/Bluetooth/ - HAL à
system/bt/btif/