web-dev-qa-db-fra.com

Android 4.3 Bluetooth instable Bluetooth basse consommation

Je développe actuellement une application qui utilisera Bluetooth Low Energy (test sur le Nexus 4). Après avoir commencé à utiliser les API BLE officielles sous Android 4.3, j'ai remarqué qu'après avoir branché un appareil pour la première fois, je n'arrivais plus vraiment à me connecter/communiquer avec cet appareil ou tout autre appareil.

En suivant le guide ici , je parviens à me connecter à un appareil, à analyser des services et des caractéristiques, et à lire/écrire/recevoir des notifications sans aucun problème. Cependant, après la déconnexion et la reconnexion, je suis souvent incapable d'analyser les services/caractéristiques ou de terminer une lecture/écriture. Je ne trouve rien dans les journaux qui indique pourquoi cela se produit.

Une fois que cela se produit, je dois désinstaller l'application, désactiver Bluetooth et redémarrer le téléphone avant qu'il ne puisse fonctionner à nouveau.

Chaque fois qu'un périphérique est déconnecté, je m'assure d'appeler close () sur l'objet BluetoothGatt et de le définir sur null. Des idées?

MODIFIER:
Sauvegardes de journaux: pour ces journaux, j’enracinais mon téléphone et augmentais les niveaux de trace des articles connexes dans /etc/bluetooth/bt_stack.conf.

Connexion réussie - Première tentative après le redémarrage du téléphone et l'installation de l'application. Je suis capable de me connecter, de découvrir tous les services/caractéristiques et de lire/écrire.

Échec de la tentative 1 - Il s'agit de la tentative suivante après la déconnexion de la connexion établie ci-dessus. Il semble que j'ai pu découvrir des caractéristiques, mais la première tentative de lecture a renvoyé une valeur nulle et s'est déconnectée peu de temps après.

Échec de la tentative 2 - Exemple où je ne suis même pas capable de découvrir des services/caractéristiques.

EDIT 2:
Le périphérique auquel je tente de me connecter est basé sur la puce CC2541 de TI. J'ai obtenu un TI SensorTag (également basé sur le CC2541) et découvert que TI a publié n Android app pour le SensorTag hier. Cependant, cette application a le même problème. J'ai testé cela sur deux autres Nexus 4 avec le même résultat: La connexion au SensorTag est réussie la première ou la deuxième fois, mais (selon les journaux) ne parvient pas à découvrir les services par la suite, provoquant toutes sortes de pannes. Je commence à me demander s'il y a un problème avec cette puce spécifique?

androidbluetoothbluetooth-lowenergyandroid-bluetoothandroid-4.3-jelly-bean
186
sa.shadow

Conseils de mise en œuvre importants

(Peut-être que certaines de ces astuces ne sont plus nécessaires en raison de Android mises à jour du système d'exploitation.)

  1. Certains appareils comme Nexus 4 avec Android 4.3 prennent plus de 45 secondes pour se connecter à l'aide d'une instance gatt existante . Contournement: fermez toujours les instances de gatt à la déconnexion et créez une nouvelle instance de gatt à chaque connexion.
  2. N'oubliez pas d'appeler Android.bluetooth.BluetoothGatt#close()
  3. Commencez un nouveau fil à l'intérieur de onLeScan(..), puis connectez-vous. Raison: BluetoothDevice#connectGatt(Context context, boolean autoConnect, BluetoothGattCallback callback) échoue toujours, s'il est appelé à l'intérieur de LeScanCallback() {...}.onLeScan(BluetoothDevice device, int rssi, byte[] scanRecord) dans le même thread sur le Samsung Galaxy S3 avec Android 4.3 (au moins pour la version JSS15J.I9300XXUGMK6)
  4. La plupart des appareils filtrent la publicité
  5. Mieux vaut ne pas utiliser Android.bluetooth.BluetoothAdapter#startLeScan(UUID[] serviceUuids, LeScanCallback callback) avec le paramètre à filtrer pour certains UUID de service car cela est complètement cassé dans le Samsung Galaxy S3 avec Android 4.3 et ne fonctionne pas pour les UUID 128 bits en général.
  6. Gatt peut toujours traiter une commande à la fois . Si plusieurs commandes sont appelées les unes après les autres, la première est annulée en raison de la nature synchrone de la mise en oeuvre de gatt.
  7. Même souvent sur les appareils modernes dotés de Android 5, le Wi-Fi interfère avec le Bluetooth et vice-versa. En dernier recours, désactivez le wifi pour stabiliser le bluetooth.

Tutoriel pour débutants

Ce didacticiel vidéo pourrait être un bon point de départ pour les nouveaux arrivants: Développement d'applications intelligentes Bluetooth pour Android http://youtu.be/x1y4tEHDwk

Le problème et les solutions décrits ci-dessous sont probablement résolus maintenant par les mises à jour du système d'exploitation.

Contourner le problème: je pourrais "stabiliser" mon application en faisant cela ...

  1. Je fournis à l'utilisateur un paramètre "Redémarrer Bluetooth". Si ce paramètre est activé, je redémarre Bluetooth à certains moments qui indiquent que le début de la pile BLE devient instable. Par exemple. si startScan renvoie false. Un bon point peut également être si servicedécouverte échoue. Je viens d'activer et désactiver Bluetooth.
  2. Je fournis un autre paramètre "Désactiver le WiFi". Si ce paramètre est activé, mon application désactive Wi-Fi lorsque l'application est en cours d'exécution (et la rallume par la suite).

Ce travail est basé sur les expériences suivantes ...

  • Le redémarrage de Bluetooth permet de résoudre les problèmes liés à BLE dans la plupart des cas.
  • Si vous désactivez le Wifi, la pile BLE devient beaucoup plus stable. Cependant, cela fonctionne également très bien sur la plupart des appareils avec le wifi activé.
  • Si vous désactivez le Wi-Fi, le redémarrage de Bluetooth rétablit complètement la pile BLE sans qu'il soit nécessaire de redémarrer le périphérique dans la plupart des cas.
176
OneWorld

Désactiver le WIFI:

Je peux également confirmer que désactiver le WIFI renforce la stabilité de Bluetooth 4.0, en particulier sur Google Nexus (j'ai un Nexus 7).

Le problème

est que l'application que je développe nécessite à la fois WIFI et continue balayage Bluetooth LE. Donc, désactiver le WIFI n'était pas une option pour moi.

De plus, je me suis rendu compte que balayage continu de Bluetooth LE peut réellement tuer la connexion WIFI et rendre le adaptateur WIFI incapable de se reconnecter à tout réseau WIFI jusqu'à ce que le balayage BLE soit activé. (Je ne suis pas sûr des réseaux mobiles et de l'Internet mobile).
Cela est vraiment arrivé sur les appareils suivants:

  • Nexus 7
  • Motorola Moto G

Cependant, la numérisation BLE avec WIFI semblait assez stable sur:

  • Samsung s4
  • HTC One

Ma solution de contournement

I recherche BLE pour une courte période de temps -4 secondes alors I désactive l'analyse pendant 3-4 secondes. Puis à nouveau.

  • Bien évidemment, je désactive toujours le balayage BLE lorsque je me connecte à un périphérique BLE.
  • Lorsque je me déconnecte d'un périphérique, je redémarre BLE (éteignez puis rallumez l'adaptateur) pour réinitialiser la pile avant de relancer l'analyse.
  • Je réinitialise également BLE lorsque la détection de services ou characteristics échoue.
  • Lorsque je reçois des données de publicité d'un appareil auquel l'application doit se connecter (disons 500 fois sans pouvoir se connecter - cela représente environ 5 à 10 secondes de publicité), je réinitialise à nouveau BLE.
15
benka

Assurez-vous que votre Nexus est associé à l'appareil. Je ne peux pas vérifier si la communication fonctionne correctement, mais vous pourrez vous connecter plusieurs fois sans redémarrer. Il semble que la première connexion ne nécessite pas d'appariement, mais toutes les tentatives ultérieures le font.

Je mettrai à jour cette réponse dans quelques jours lorsque je teste la découverte du service et que gatt lit et écrit les demandes sans redémarrage.

EDIT: Il s’est avéré que j’étais en train de tester une version de micrologiciel de développement (notre capteur) qui posait des problèmes si elle n’était pas couplée. La dernière version de notre micrologiciel de production fonctionne bien sur les 2540 et 2541.

EDIT: J'ai remarqué que sur le Nexus 7 2013, les connexions sont plus stables lorsque le WiFi est désactivé. J'aimerais savoir si cela aide quelqu'un d'autre.

EDIT: Je semble avoir eu à l'envers avec le jumelage. Tout fonctionne bien lorsqu'il n'est pas jumelé. Après l'association, je ressens exactement les mêmes symptômes que l'OP. Nous ne savons pas encore si cela est lié à notre microprogramme ou à l'API Android_BLE. Soyez prudent si vous testez ceci, car une fois couplé, vous ne pourrez peut-être pas dissocier à cause d'un bogue expliqué dans 3b de ceci post .

6
Mikt25

Certains modèles présentent un défaut: https://code.google.com/p/Android/issues/detail?id=18044

D'autre part, dans mon cas, le problème était que ma connexion n'était pas correctement fermée dans la méthode onDestroy. Après la fermeture correcte, le problème pour moi n’existe pas, que le wifi soit activé ou désactivé.

btGatt.disconnect();
btGatt.close();
4
Krystian

Je faisais face à un problème similaire. Ma solution était

if (Build.VERSION.SDK_INT >= 23) {
  mBluetoothGatt = device.connectGatt(this, false, mGattCallback, BluetoothDevice.TRANSPORT_LE);
} else {
  mBluetoothGatt = device.connectGatt(this, false, mGattCallback);
}

& appelant près après la déconnexion.

1
Sam Reyes