How to Prevent Android Bluetooth Rfcomm Connection from Dying Immediately After .Connect()

How to prevent Android bluetooth RFCOMM connection from dying immediately after .connect()?

Try to change your code for creating RfcommSocket:

sock = zee.createRfcommSocketToServiceRecord(
                      UUID.fromString("8e1f0cf7-508f-4875-b62c-fbb67fd34812"));

for this code:

Method m = zee.getClass().getMethod("createRfcommSocket", new Class[] { int.class });
sock = (BluetoothSocket) m.invoke(device, 1);

Also try to change argument value in range 1-3 in this m.invoke(device, 1);
When connection will be Connected, but aborted when you try reading, call in some loop your method test() again.
As simple:

for(int i=0;i<3;i++){  if(!testDone) test(); }

Bluetooth RFCOMM connection couldn't be established consecutively on Android 4.2

I have finally figured out the solution.

It turns out that it's not a bug in the new Bluetooth driver. It's a corner case not considered in Bluetooth sample application, more specifically, BluetoothChat project, provided by Android SDK.

In the Bluetooth service code inside BluetoothChat sample project, when connection is failed or lost, it always starts the service over to restart listening mode. It's no problem when the phone is used as server, however, in some scenarios when the phone is used as client, once it goes into listening mode, you can't connect to other servers. Because in "connect" function, it doesn't cancel (In)SecureAcceptThread. So essentially you are listening to other connections as server while trying to connect to other servers as client. It's conflicting.

The way to solve this issue is, if you are sure your phone will not be used as server listening to incoming connection, then simply remove the code to restart listening mode once connection is failed or stopped.

Android Bluetooth SPP connection to seems to go dead after a couple of seconds

The Tab and (in my experience with 6 different devices) all Samsung devices have TERRIBLE Bluetooth SPP implementations. I'd suggest choosing a different device.

Also, I would check that you are calling flush on the OutputStream, particularly if you are not sending line separators.

---

Related Topics