Android 4.3 Bluetooth Low Energy instable

Question

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

En suivant le guide aquí Je peux me connecter avec succès à un appareil, analyser les services et les caractéristiques, et lire/écrire/recevoir des notifications sans aucun problème. Cependant, après m'être déconnecté et reconnecté, je suis souvent incapable d'analyser les services/caractéristiques ou d'effectuer une lecture/écriture. Je ne trouve rien dans les journaux qui indique pourquoi cela se produit.

Lorsque cela se produit, je dois désinstaller l'application, désactiver le Bluetooth et redémarrer le téléphone avant qu'elle ne fonctionne à nouveau.

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

---

EDIT :
Décharges de journaux : Pour ces journaux, j'ai enraciné mon téléphone et augmenté le niveau de traçage des éléments connexes dans /etc/bluetooth/bt_stack.conf.

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

Échec de la première tentative - Il s'agit de la tentative suivante après la déconnexion de la connexion réussie 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 après.

Échec de la deuxième tentative - Un exemple où je ne suis même pas capable de découvrir les services/caractéristiques.

---

EDIT 2 :
Le dispositif auquel j'essaie de me connecter est basé sur la puce CC2541 de TI. J'ai obtenu un TI SensorTag (également basé sur le CC2541) pour jouer avec et a découvert que TI a sorti une application Android pour le SensorTag hier. Cependant, cette application a le même problème. J'ai testé ceci sur deux autres Nexus 4s 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, ce qui provoque toutes sortes de plantages. Je commence à me demander si c'est un problème avec cette puce spécifique ?

Answer 1

Conseils importants pour la mise en œuvre

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

1. Certains appareils comme le Nexus 4 avec Android 4.3 il faut plus de 45 secondes pour se connecter en utilisant 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 de discussion à l'intérieur onLeScan(..) et ensuite se connecter. Raison : BluetoothDevice#connectGatt(Context context, boolean autoConnect, BluetoothGattCallback callback) échoue toujours, si elle est appelée à l'intérieur de LeScanCallback() {...}.onLeScan(BluetoothDevice device, int rssi, byte[] scanRecord) dans le même fil de discussion sur 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 pour filtrer certains UUID de service parce que c'est complètement cassé dans 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 l'une après l'autre, la première est annulée. en raison de la nature synchrone de l'implémentation de gatt.
7. Je constate souvent, même sur les appareils modernes sous Android 5, que le Wifi interfère avec le Bluetooth et vice versa. En dernier recours, éteignez le wifi pour stabiliser le bluetooth.

Tutoriel pour les débutants

Un bon point de départ pour les nouveaux venus pourrait être ce tutoriel vidéo : Développer des applications Bluetooth Smart pour Android http://youtu.be/x1y4tEHDwk0

Le problème et la solution décrite ci-dessous sont probablement corrigés par les mises à jour du système d'exploitation.

Travailler autour : Je pourrais "stabiliser" mon application en faisant ça...

1. Je propose à l'utilisateur un paramètre "Redémarrer Bluetooth". Si ce paramètre est activé, je redémarre Bluetooth à certains moments qui indiquent que la pile BLE commence à devenir instable. Par exemple, si startScan renvoie false. Un bon point peut également être si serviceDiscovery échoue. J'éteins et rallume simplement Bluetooth.
2. Je propose un autre paramètre "Turn off WiFi". Si ce paramètre est activé, mon application désactive le Wifi lorsqu'elle fonctionne (et le réactive ensuite).

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

• Le redémarrage de Bluetooth permet de résoudre les problèmes de BLE dans la plupart des cas.
• Si vous désactivez le Wifi, la pile BLE devient beaucoup plus stable. Cependant, elle fonctionne aussi très bien sur la plupart des appareils avec le wifi activé.
• Si vous désactivez le Wifi, le redémarrage de Bluetooth récupère entièrement la pile BLE sans qu'il soit nécessaire de redémarrer l'appareil dans la plupart des cas.

Answer 2

Désactiver le WIFI :

Je peux aussi confirmer que désactiver le WIFI rend Bluetooth 4.0 plus stable, notamment sur les Google Nexus (j'ai un Nexus 7).

Le problème

c'est que l'application que je développe besoins les deux WIFI et continuellement 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 en fait tuer la connexion WIFI et faire le L'adaptateur WIFI ne peut pas 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 s'est produit sur les appareils suivants :

• Nexus 7
• Motorola Moto G

Cependant, le balayage BLE avec WIFI activé semble assez stable :

• Samsung S4
• HTC One

Ma solution de rechange

I balayage BLE pour une courte période de temps 3-4 secondes alors je éteindre le scan pendant 3-4 secondes . Puis à nouveau ON.

• Évidemment, je désactive toujours le balayage BLE lorsque je me connecte à un appareil BLE.
• Lorsque je me déconnecte d'un appareil, je redémarre BLE (en éteignant puis en rallumant l'adaptateur) pour réinitialiser la pile avant de relancer le balayage.
• J'ai également réinitialisé le BLE lors de la découverte services o characteristics échoue.
• Lorsque je reçois des données de publicité d'un appareil auquel l'application devrait se connecter (disons 500 fois sans pouvoir se connecter - ce qui représente environ 5-10 secondes de publicité), je réinitialise BLE à nouveau.

Answer 3

Assurez-vous que votre Nexus est apparié à l'appareil. Je ne peux pas vérifier si la communication fonctionne correctement ou non, mais vous pourrez vous connecter plus d'une fois sans redémarrage. Il semble que la première connexion ne nécessite pas d'appairage mais que toutes les tentatives suivantes le font.

Je mettrai à jour cette réponse dans quelques jours lorsque je testerai la découverte de services et les demandes de lecture et d'écriture de gatt sans redémarrage.

EDIT : Il s'avère que je testais sur une version de micrologiciel de développement (notre capteur) qui causait des problèmes si elle n'était pas appariée. Notre dernière version du firmware de production fonctionne parfaitement sur les 2540 et 2541.

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

EDIT : Il semble que j'ai fait l'inverse avec l'appariement. Tout fonctionne bien quand il n'est pas appairé. Après l'appairage, je ressens exactement les mêmes symptômes que le PO. On ne sait pas encore si cela est lié à notre firmware ou à l'API Android BLE. Soyez prudent si vous testez ceci parce qu'une fois apparié, vous ne pourrez peut-être pas vous désapparier à cause d'un bug expliqué dans le paragraphe 3b de ce document. poste .

Answer 4

Dans certains modèles, il y a un défaut : https://code.google.com/p/Android/issues/detail?id=180440

Par contre, 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 n'existe plus pour moi, peu importe que le wifi soit activé ou désactivé.

btGatt.disconnect();
btGatt.close();

Answer 5

J'étais confronté à 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);
}

& appel proche après déconnexion.