Voici le scénario :
Je dois écrire une application pour Android pour créer un socket RFCOMM vers un PC avec un dongle Bluetooth (je vais également écrire le serveur).
Ma demande est que l'utilisateur n'ait pas à apparier les appareils manuellement.
En fait, avec un gros bidouillage, j'utilise le createInsecureRfcommSocket.
Un petit scénario : j'ai une application Android qui échange des informations avec un boîtier Linux avec un socket RFCOMM ouvert. Je peux définir manuellement le code PIN sur les appareils (le codage en dur est une option)
Je recherche différentes alternatives :
Écrire un wrapper JNI
Comme cela a été fait ici par Max Kellermann, je peux écrire une couche JNI pour faire toute la phase d'appariement. Cela devrait être une bonne option, mais il y a un problème :
La NDK 4b ne fournit pas de bibliothèques libbluetooth, donc -lbluetooth échoue, tout comme la NDK v.3.
Options :
- Trouver la NDK 1.5 (qui inclut lib bluetooth). Après des jours de recherche sur le web, je n'ai pas réussi à trouver. Quelqu'un l'a ou sait où je peux le trouver ?
- Compiler libbluetooth pour Android moi-même et les utiliser pour -lbluetooth. Pas de chance là, je ne suis pas capable de les compiler. Des idées ?
Utiliser quelque chose exposé par les API
Quelqu'un sait comment je peux utiliser createRfcommSocketToServiceRecord et faire en sorte que l'utilisateur n'ait pas à apparier manuellement l'appareil ? Est-ce possible ? Comment devrais-je écrire le serveur ?
Quelque chose que je ne connais pas
Peut-être (certainement !) il y a quelque chose que je ne sais pas. Peut-être que je peux utiliser autre chose ? Pas de RFCOMM ? SDP ?
Peut-être que je peux appairer manuellement avec l'API Android ?
J'espère avoir été assez clair, sinon n'hésitez pas à demander. Et encore une fois, comme ce n'est pas la première fois, je suis entre vos mains :)
Merci pour tout le soutien les gars !
9 votes
Je fais une supposition, mais je ne serais pas surpris si c'était intentionnellement conçu de sorte que l'implication de l'utilisateur (l'approbation) soit nécessaire pour l'appariement. Au moins, cela serait cohérent avec d'autres endroits où la conception Android nécessite une interaction de l'utilisateur pour des raisons de sécurité.
0 votes
Oui, mais les api "officielles" ne sont pas le seul moyen. C'est pourquoi je me renseigne sur ndk 1.5, pour compiler la libbluetooth ou les autres fonctions @hide.
0 votes
Si libbluetooth a été supprimée, il est très probable que l'ancienne version ne fonctionnerait pas sur une version plus récente d'Android même si vous la trouviez. C'est l'avertissement constant contre l'utilisation d'API non publiques - des changements futurs peuvent les rendre inutilisables.
0 votes
Je ne suis pas sûr de comprendre pourquoi vous voulez que cela fonctionne sans avoir besoin d'appairer manuellement (ce qui est une chose assez banale pour l'utilisateur à faire et n'est qu'une procédure unique).
0 votes
Je comprends votre point de vue, et je suis d'accord. Mais c'est une exigence pour un projet auquel je participe. Et l'explication est assez banale, réfléchissons à un type de travail qui nécessite de vérifier beaucoup de différentes "choses" qui exposent certains services bluetooth. S'appairer à chaque fois avec l'appareil est simplement une perte de temps.
0 votes
Est-ce cela dont vous avez besoin code.google.com/p/androidobex/downloads/… ?
1 votes
Enrico, je suis sûr que cela ne répond pas à ta question, mais peut-être vaut-il la peine de demander -- y a-t-il d'autres mécanismes de communication que tu peux utiliser pour accomplir ce travail? BT est ennuyeux, un peu. Une chose que tu pourrais faire est d'encoder tes données dans le nom du dispositif BT que ton téléphone diffuse, et ensuite une recherche de dispositifs obtiendra ce nom (qui est quelques octets de données).
0 votes
Quel est votre cas d'utilisation ici? Si vous interrogez des éléments pour savoir si un service est disponible sur un appareil, ne serait-il pas préférable d'utiliser SDP? Je suis assez sûr que vous n'avez pas besoin de coupler pour la découverte de services.
3 votes
Merci à tous pour les indications. Avec ordre : @sugarynugs merci, j'ai réussi à compiler par moi-même mais ce n'est pas suffisant. Android lui-même a une façon très étrange d'utiliser bluez... @mchang Nous utilisons actuellement à la fois la connexion BT et wifi, mais dans certains scénarios le BT est obligatoire. @Gaz oui, mais avec sdp je ne peux trouver que des services, mais j'ai besoin d'avoir un canal sur lequel communiquer... Une fois que j'ai trouvé le socket rfcomm diffusé par sdp, je dois me connecter à lui, donc le couplage est nécessaire...