Discussion :

[atha2]

Bonjour,

Je travail actuellement sur une application android qui plante fréquement lors que je tente d'établir une connexion bluetooth. Quand je regarde au débogueur, ça plante sur l'appel

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

clientSocket.connect();

Enfin je dis que ça plante en faite non c'est juste que la fonction connect est bloquante et quelle ne sort jamais de cette état bloquant. Et donc la suite du code n'est jamais appelé.
Voici les logs correspondant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
09-25 17:39:09.255: D/BLZ20_ASOCKWRP(16017): asocket_connect
09-25 17:39:09.255: I/BLZ20_WRAPPER(16017): blz20_wrp_connect: s 53
09-25 17:39:09.255: D/BLZ20_WRAPPER(16017): blz20_wrp_connect:  fd (-1:53), bta -1, rc 0, wflags 0x0, cflags 0x0, port 0
09-25 17:39:09.255: I/BLZ20_WRAPPER(16017): __connect_prot_rfcomm: connecting to... de9dee671100, rc chan 6
09-25 17:39:09.255: I/BLZ20_WRAPPER(16017): __connect_prot_rfcomm: non blocking mode
09-25 17:39:09.255: I/BTL_IFC(16017): send_ctrl_msg: [BTL_IFC CTRL] send BTLIF_BTS_RFC_CON_REQ (BTS) 23 pbytes (hdl 52)
09-25 17:39:09.255: D/BLZ20_WRAPPER(16017): blz20_wrp_connect: success
09-25 17:39:09.255: I/BLZ20_WRAPPER(16017): blz20_wrp_poll: nfds 2, timeout -1 ms
09-25 17:39:09.255: D/BLZ20_WRAPPER(16017): blz20_wrp_poll: pending connect fd (-1:53), bta -1, rc 6, wflags 0x0, cflags 0x1, port 0
09-25 17:39:09.255: D/BLZ20_WRAPPER(16017): btlif_wait_response: id(s) |BTLIF_BTS_RFC_CON_RSP|BTLIF_BTS_RFC_DISC_IND|

A noter qu'il est possible pour une raison ou une autre que le serveur ne réponde pas. Cela peut-il poser problème ?
Je galère depuis quelque jour sur des problèmes de connexion.
Le problème n'arrive généralement qu'au bout de 3 ou 4 lancement de l'appli puis tout le temps une fois le bug apparu.

Quelqu'un aurai quelque piste pour résoudre ce type de problème ?

Je précise que je débute avec le bluetooth et à un degré moindre avec Android.

[nicroman]

On peut spécifier soit même le timeout:
http://developer.android.com/referen...tAddress, int)

Déjà, cela résoudra les problèmes de connexion lentes ou foireuse...
Ensuite dans le socket, on peut faire des appels à setSoTimeout je crois pour spécifier les time-out en lecture...


On pourra peut-être en dire plus avec un poil plus de code que le simple "clientSocket.connect();" (qui au passage n'existe même pas ^^ )

[atha2]

merci de ta réponse nicroman.
J'utilise la classe BluetoothSocket qui n'étend pas socket. Celle-ci ne permet pas de définir un timeout. Et malgré que la connexion soit fait dans un Thread séparé, cela fait planté l'application sans aucun message d'erreur

Voici le code complet de la connexion :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
private class ConnectThread extends Thread {
        private final BluetoothDevice mmDevice;
 
        @SuppressLint("NewApi")
        public ConnectThread(BluetoothDevice device) {
            Log.v("ConnectionHelper", "ConnectThread");
 
            mmDevice = device;
            BluetoothSocket tmp = null;
 
            // Get a BluetoothSocket for a connection with the
            // given BluetoothDevice
            try {
//                Method m = device.getClass().getMethod("createRfcommSocket", new Class[] { int.class });
//                tmp = (BluetoothSocket) m.invoke(device, 1);
                   tmp = device.createRfcommSocketToServiceRecord(SERVER_UUID);
                // tmp =
                // device.createInsecureRfcommSocketToServiceRecord(SERVER_UUID);
 
            }catch (IOException e) {
                Log.e(TAG, "create() failed", e);
            }  /*catch (SecurityException e) {
                Log.e("createRfcommSocket", "SecurityException " + e.getMessage());
            } catch (NoSuchMethodException e) {
                Log.e("createRfcommSocket", "NoSuchMethodException " + e.getMessage());
 
            } catch (IllegalArgumentException e) {
                Log.e("createRfcommSocket", "IllegalArgumentException " + e.getMessage());
 
            } catch (IllegalAccessException e) {
                Log.e("createRfcommSocket", "IllegalAccessException " + e.getMessage());
 
            } catch (InvocationTargetException e) {
                Log.e("createRfcommSocket", "InvocationTargetException " + e.getMessage());
 
            }*/
 
            ConnectionHelper.this.clientSocket = tmp;
        }
 
        @Override
        public void run() {
            Log.i(TAG, "BEGIN mConnectThread");
            setName("ConnectThread");
 
            // Always cancel discovery because it will slow down a connection
            mAdapter.cancelDiscovery();
 
            // Make a connection to the BluetoothSocket
            try {
                // This is a blocking call and will only return on a
                // successful connection or an exception
                ConnectionHelper.this.clientSocket.connect();
                ConnectionHelper.this.outputStream = ConnectionHelper.this.clientSocket
                        .getOutputStream();
                ConnectionHelper.this.inputStream = ConnectionHelper.this.clientSocket
                        .getInputStream();
                ConnectionHelper.this.buffInputStream = new BufferedReader(new InputStreamReader(inputStream));
            } catch (IOException e) {
                connectionFailed(e);
                ConnectionHelper.this.closeConnection();
 
                // Start the service over to restart listening mode
                ConnectionHelper.this.start();
                return;
            }
 
            // Reset the ConnectThread because we're done
            synchronized (ConnectionHelper.this) {
                mConnectThread = null;
            }
 
            // Start the connected thread
            connected(clientSocket, mmDevice);
        }
 
        public void cancel() {
            ConnectionHelper.this.closeConnection();
        }
    }

D'après mes recherches il semble que ce problème arrive sur la plupart des téléphone Samsung.

[nicroman]

Je ne vois pas pourquoi cela ferait planter l'appli....
Je donne en vrac les idées qui me viennent.....

Est ce-que c'est createRfcommSocketToServiceRecord qui plante ?
Je ne vois pas de "BEGIN mConnectThread" dans logcat....

Le "cancel" (qui a priori est appelé depuis l'activité quand on la quitte donc sur le onDestroy) ne fait pas de "interrupt()" donc ne va pas interrompre le thread si celui-ci est en attente d'IO.