BLE , iOS et Android
Jean-Pierre
Membre
Bonjour,
Faire communiquer un iPhone, le centralManager, et un device android - peripheral - avec BLE, telle est ma petite mission.
Depuis que mes "hautes autorités" ont décidé de supprimer une puce BLE Cypress ordinaire - tout marchait très bien - pour à la place tenter d'utiliser du BLE android natif, mon appli iOS ne dialogue pas avec le device Android. En fait le iOS / CoreBluetooth n'envoie plus le dialogue / Alert view proposant à l'utilisateur l'appairage.
Certains des articles que j'ai lu disent qu'il faudrait que le device android soit certifié MFI, qu'Apple bloque la connection, etc., et donc que c'est impossible. Mais ces articles sont anciens, alors y a -t-il un moyen de réussir l'appairage?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Ce n'est pas clair.
Tu communiques encore en BLE ?
Dans mes souvenirs pour faire un trigger sur la demande d'appairage en BLE, il faut que tu fasses un read sur une characteristic qui a en propriété encryption demandée : CBCharacteristicPropertyNotifyEncryptionRequired ou CBCharacteristicPropertyIndicateEncryptionRequired si mes souvenirs sont bons.
Le plus simple, serait de créer rapidement une app iOS, avec 1 service, et autant de characteristic que de CBCharacteristicProperty qui existe, et en mettant une différente à chaque fois.
Ensuite, avec une application comme LightBlue (sur l'AppStore), tu le trouves, et tu lis les characteristics une à une pour trouver celle qui demande l'appairage.
Merci pour ta réponse. Je regarde et te répond en détail.
Nous avons finalement réussi à faire dialoguer iOS et Android en BLE.
La mission:
L'appli iOS, 9.3, doit communiquer en BLE avec un objet connecté.
1ère étape:
Le BLE de l'objet connecté est assuré par une puce dédiée Cypress. Là tout va bien, l'appli iOS , central role, dialogue sans problème avec l'objet connecté, peripheral role.
2ème étape:
La puce Cypress est retirée de l'objet. La communication BLE est alors assurée 'nativement' par le stack Android - l'objet connecté est un Android... un quoi? Bon et là , plus rien ne se passe.. Plus d'appairage, rien du tout. iOS semble couper la connection.
Après moultes errances, le lien posté par Joanna nous a mis sur la bonne direction: les applications iOS et Android BLEMingle. Mon collègue Android s'en est inspiré pour modifier son code et le dialogue s'est finalement établi. Le plus curieux c'est que je n'ai rien eu à changer dans mon implémentation BLE, calquée sur le Core Bluetooth Programming Guide de Apple. J'ai même gardé le filtrage dans la méthode central.scanForPeripherals(withServices: [serviceUUID], options: nil).
Les performances et la fiabilité sont équivalentes à la solution avec Cypress. Alors tout va bien?
Il y a cependant un "petit" bémol: l'habituelle AlertView qui demande à l'utilisateur iOS la permission de procéder à l'appairage n'apparait plus. L'appairage se fait sans elle, automatiquement.
Et là s'ouvre un tout autre chapitre: Apple va-t-elle accepter un tel contournement de sécurité de la part d'un objet qui n'est pas certifié MFI? https://developer.apple.com/programs/mfi/(et Android passoire de surcroit)
Certains disent que les testeurs d'Apple n'auront pas l'objet en main et donc que l'appli sera acceptée sans problème. Qu'en pensez-vous?
Effectivement, ça peut passer.
J'vais reparler de mes deux properties précédentes : CBCharacteristicPropertyNotifyEncryptionRequired ou CBCharacteristicPropertyIndicateEncryptionRequired
De mes souvenirs, ce sont vraiment celles là qui vont déclencher l'appairage.
Si tu as encore un device avec la puce, je t'invite à la découverte de chaque characteristics de lire ses CBCharacteristicProperties. C'est un enum/bit flag normalement.
Il n'y a pas de contournement car le BLE ne nécessite pas de MFi. Une vidéo peut-être demandée, ou vu que c'est une app Android, l'application Android peut-être pourrait être fournie.
J'ai informé mes clients qu'en faisant ce choix de BLE Android natif, cela pouvait coincer. Ils veulent aller au bout, alors réponse dans deux mois...