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.