Bluetooth RFCOMM / SDP connection to a RS232 adapter in android

Question

Hello All,

I am trying to use the Bluetooth Chat sample API app that google provides to connect to a bluetooth RS232 adapter hooked up to another device. Here is the app for reference:

http://developer.android.com/resources/samples/BluetoothChat/index.html

And here is the spec sheet for the RS232 connector just for reference:

http://serialio.com/download/Docs/BlueSnap-guide-4.77_Commands.pdf

Well the problem is that when I go to connect to the device with:

mmSocket.connect(); (BluetoothSocket::connect())

I always get an IOException error thrown by the connect() method. When I do a toString on the exception I get "Service discovery failed". My question is mostly what are the cases that would cause an IOException to get thrown in the connect method? I know those are in the source somewhere but I don't know exactly how the java layer that you write apps in and the C/C++ layer that contains the actual stacks interface. I know that it uses the bluez bluetooth stack which is written in C/C++ but not sure how that ties into the java layer which is what I would think is throwing the exception. Any help on pointing me to where I can try to dissect this issue would be incredible.

Also just to note I am able to pair with the RS232 adapter just fine but I am never able to actually connect. Here is the logcat output for more reference:

I/ActivityManager( 1018): Displayed activity com.example.android.BluetoothChat/.DeviceListActivity: 326 ms (total 326 ms)
E/BluetoothService.cpp( 1018): stopDiscoveryNative: D-Bus error in StopDiscovery: org.bluez.Error.Failed (Invalid discovery session)
D/BluetoothChat( 1729): onActivityResult -1
D/BluetoothChatService( 1729): connect to: 00:06:66:03:0C:51
D/BluetoothChatService( 1729): setState() STATE_LISTEN -> STATE_CONNECTING
E/BluetoothChat( 1729): + ON RESUME +
I/BluetoothChat( 1729): MESSAGE_STATE_CHANGE: STATE_CONNECTING
I/BluetoothChatService( 1729): BEGIN mConnectThread
E/BluetoothService.cpp( 1018): stopDiscoveryNative: D-Bus error in StopDiscovery: org.bluez.Error.Failed (Invalid discovery session)
E/BluetoothEventLoop.cpp( 1018): event_filter: Received signal org.bluez.Device:PropertyChanged from /org/bluez/1498/hci0/dev_00_06_66_03_0C_51
I/BluetoothChatService( 1729): CONNECTION FAIL TOSTRING: java.io.IOException: Service discovery failed
D/BluetoothChatService( 1729): setState() STATE_CONNECTING -> STATE_LISTEN
D/BluetoothChatService( 1729): start
D/BluetoothChatService( 1729): setState() STATE_LISTEN -> STATE_LISTEN
I/BluetoothChat( 1729): MESSAGE_STATE_CHANGE: STATE_LISTEN
V/BluetoothEventRedirector( 1080): Received android.bleutooth.device.action.UUID
I/NotificationService( 1018): enqueueToast pkg=com.example.android.BluetoothChat callback=android.app.ITransientNotification$Stub$Proxy@446327c8 duration=0
I/BluetoothChat( 1729): MESSAGE_STATE_CHANGE: STATE_LISTEN
E/BluetoothEventLoop.cpp( 1018): event_filter: Received signal org.bluez.Device:PropertyChanged from /org/bluez/1498/hci0/dev_00_06_66_03_0C_51
V/BluetoothEventRedirector( 1080): Received android.bleutooth.device.action.UUID

The device I'm trying to connect to is the 00:06:66:03:0C:51 which I can scan for and apparently pair with just fine.

---

The below is merged from a similar question which was successfully resolved by the selected answer here:

How can one connect to an rfcomm device other than another phone in Android?

The Android API provides examples of using listenUsingRfcommWithServiceRecord() to set up a socket and createRfcommSocketToServiceRecord() to connect to that socket.

I'm trying to connect to an embedded device with a BlueSMiRF Gold chip. My working Python code (using the PyBluez library), which I'd like to port to Android, is as follows:

sock = bluetooth.BluetoothSocket(proto=bluetooth.RFCOMM)
sock.connect((device_addr, 1))
return sock.makefile()

...so the service to connect to is simply defined as channel 1, without any SDP lookup.

As the only documented mechanism I see in the Android API does SDP lookup of a UUID, I'm slightly at a loss. Using "sdptool browse" from my Linux host comes up empty, so I surmise that the chip in question simply lacks SDP support.

Answer 1

Ok the short answer is I had to use this UUID in order to connect to my SPP device:

private static final UUID MY_UUID = UUID.fromString("00001101-0000-1000-8000-00805F9B34FB");

I tried to change it since I thought that only the "1101" part was important since I see that mentioned with SPP stuff all over the place on the intertubes but that made it not connect again. Apparently that specific UUID is what is supposed to be used to connect to generic SPP devices. Anyway just figured I'd post it up here so anyone who this sort of problem has an answer. Took me about 3 days to find it LOL!

Answer 2

I guess it is related to a sony-ericsson phones bug (see here).

I was able to connect from/to an android 2.0 device and my mac using bluetooth and a totally made-up UUID. Trying to make the same thing with a j2me device (a sony ericsson w910i) was working only if the android was the server, otherwise I get the same exception as you.

The UUID you are using, as far as I know, is a "base address" for the spp profile, and in the ServiceClassIDList field of the ServiceRecord returned by the server device when issuing a service discovery, it should be listed AFTER the UUID you decided to use..apparentely this is not the case in some situations (e.g. my phone first listed the generic UUID and then my custom UUID).

Looks like it's the same situation here. You can try to manually change the ServiceRecord and return the proper ServiceClassIDList. Maybe it will work for you..unfortunately, my stupid cell phone refuse to change it :(

PS. a strange thing is that my mac is indeed able to see the service, even if the ServiceRecord is "broken", I guess that android just bother to see the first UUID in the ServiceClassIDList, while my pc go through the list searching every element. But this is just my supposition :)

Answer 3

What baud rate do you have your bluetooth device set at? I'm connected, but my data is showing up as the typical garbled mush you get with mixed baud rates. I have mine set to 57600, this is what I've seen other folks use. Oh, thanks for posting your results the UUID had me working for a few days as well.

Answer 4

If 'sdptool browse' reports no information about the device try 'sdptool records [device-mac-here]'