With only one specific Bluetooth module, SPP.createRfcommSocketToServiceRecord () suddenly stops working, but the reflection method works

Question

My application connects to the Bluetooth SPP modules, creating and processing connections to a large extent, as described in the Bluetooth documentation for Android . That is, in my connection thread, I was used to create the connection, simply using:

socket = device.createRfcommSocketToServiceRecord(MY_UUID) 

where the UUID is the "well known" SPU UUID, 00001101-0000-1000-8000-00805F9B34FB.

The Bluetooth devices I'm connecting to are small Bluetooth adapters / serial interface. I have three that I used for testing. Two of them are “Linvor” Bluetooth for TTL-level serial circuit packs that are currently located all over eBay, which are identical; and the third is the manufacturer’s fully enclosed adapter.

During the development of this application, I regularly tested on different devices, starting from version Android 2.2.1 (my old Archos 101) and ending with the Archos Honeycomb device. The device I tested mostly is my Desire HD, which currently has Android version 2.3.5. For a year or so I worked on this, I can say with confidence that I have never had a connection problem.

Yesterday, while testing with my Desire HD (2.3.5), I discovered that the application would no longer connect to my Linvor Bluetooth board, which I have been working with mostly recently. After receiving the socket using the line of code above, when trying socket.connect() I immediately get an IOException from Unable to start discovery .

The next thing I did was to switch to another spare Linvor module and try to connect and connect. The application is very simple. Then I exchanged for my third packaged Bluetooth adapter, and the app connected to it is fine too. Returning to my first Linvor module, the application still refuses to connect. I guarantee that I will abandon the “faulty” Linvor device on my Desire HD, turn off Bluetooth, turn off the phone, remove and reinsert the battery, turn on the power, try again, etc., and then try again. The app still refuses to connect to this first Linvor module, but it connects perfectly to the second Linvor module and another adapter module.

Then I grab my Archos 101 (2.2.1) and run the slightly older builds of my application that are still installed on it. Archos 101 instantly connects to a failed Linvor module.

At this point, I begin to wonder if any device, that is, my Desire HD, or perhaps more likely the Linvor module, can have a damaged entry in its flash memory table for paired devices. In other words, something inside this first Linvor module means that it no longer accepts the connection (although it accepts a pair) from my Desire HD, and yet it will still accept connections from other devices; and at the same time, my Desire HD can happily connect to other devices, as it always did, including another spare Linvor module.

After hours of scratching and despairing my head, I decided to try out the communication method as described in Michael's answer here . This is something that I have heard quite a lot about, and I got the impression that it applies to Android 2.2 and below. However, for the whole year that I worked with Bluetooth SPP from different Android devices, I never had to use it, because .createRfcommSocketToServiceRecord() always worked for me. Therefore, I use the code provided in Michael's answer to this question to create my socket , and, to my surprise, my Desire HD connects to the "faulty" Linvor module.

So, to repeat, the situation looks something like this:

Over the past year, I have been able to regularly use .createRfcommSocketToServiceRecord() on my 2.2.1 and 2.3.5 devices to connect to my three Bluetooth SPP adapters.

Then, on one specific day, without any changes in the software on the phones or on my Bluetooth adapters, the first of the adapters suddenly requires a reflection method to connect to the job; the other two adapters (one of which is the same type as the first) continue to connect to my application, simply using .createRfcommSocketToServiceRecord() . Please note that no changes made to my Bluetooth code occurred immediately before these sudden changes in behavior.

What's going on here?

Can anyone advise me at what level of the Android version I need to “crack” reflection? I got the impression that you no longer need, say, 2.3.5 (my desire is HD). It is right?

Is / is the nature of the error with .createRfcommSocketToServiceRecord() , so the connections usually work, but sometimes they don't work depending on the moon phase?

Here is the output of Logcat when a connection to this particular Linvor module occurs when using .createRfcommSocketToServiceRecord() :

 01-29 10:22:00.004: D/View(8165): onTouchEvent: viewFlags: 0x18005001 01-29 10:22:00.014: D/View(8165): onTouchEvent: isFocusable: true, isFocusableInTouchMode: false, isFocused: false; focusTaken: false 01-29 10:22:00.034: D/WindowManagerImpl(8165): finishRemoveViewLocked, mViews 2 : com.android.internal.policy.impl.PhoneWindow$DecorView@406215d8 01-29 10:22:00.074: I/BLZ20_WRAPPER(8165): blz20_wrp_socket: fam 31, type 1, prot BTPROTO_RFCOMM 01-29 10:22:00.084: D/BLZ20_WRAPPER(8165): blz20_init: initializing... 01-29 10:22:00.084: D/BTL_IFC_WRP(8165): wsactive_init: init active list 01-29 10:22:00.084: I/BTL_IFC(8165): main_client_thread: Client main thread starting 01-29 10:22:00.194: D/BLZ20_WRAPPER(8165): blz20_init: success 01-29 10:22:00.194: I/BTL_IFC(8165): BTL_IFC_RegisterSubSystem: Register subsystem [BTS] 01-29 10:22:00.194: I/BTL_IFC(8165): btl_ifc_ctrl_connect: Connect control channel for subsystem [BTS] 01-29 10:22:00.194: D/BTL_IFC_WRP(8165): wrp_sock_create: CTRL 01-29 10:22:00.194: D/BTL_IFC_WRP(8165): wrp_alloc_new_sock: wrp_alloc_new_sock sub 1 01-29 10:22:00.194: D/BTL_IFC_WRP(8165): wrp_sock_create: 66 01-29 10:22:00.194: D/BTL_IFC_WRP(8165): wrp_sock_connect: wrp_sock_connect brcm.bt.btlif:9000 (66) 01-29 10:22:00.194: D/BTL_IFC_WRP(8165): wrp_sock_connect: BTLIF_MAKE_LOCAL_SERVER_NAME return name: brcm.bt.btlif.9000 01-29 10:22:00.194: D/BTL_IFC_WRP(8165): wrp_sock_connect: wrp_sock_connect ret:0 server name:brcm.bt.btlif.9000 01-29 10:22:00.194: I/BTL_IFC_WRP(8165): wrp_sock_connect: Connected. (66) 01-29 10:22:00.194: I/BTL_IFC(8165): send_ctrl_msg: [BTL_IFC CTRL] send BTLIF_REGISTER_SUBSYS_REQ (BTS) 0 pbytes (hdl 66) 01-29 10:22:00.194: D/BTL_IFC(8165): BTL_IFC_RegisterSubSystem: add new ctrl fd to active set 01-29 10:22:00.194: D/BTL_IFC_WRP(8165): wrp_wsock_create: BTS 01-29 10:22:00.194: D/BTL_IFC_WRP(8165): wrp_alloc_new_sock: wrp_alloc_new_sock sub 16 01-29 10:22:00.194: D/BTL_IFC_WRP(8165): wrp_wsock_create: 67 01-29 10:22:00.194: D/BLZ20_WRAPPER(8165): btsk_alloc_add: success 01-29 10:22:00.194: D/BLZ20_WRAPPER(8165): btsk_dump_list: fd (-1:67), bta -1, rc 0, wflags 0x0, cflags 0x0, port 0 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_socket: return 67 01-29 10:22:00.194: D/BLZ20_WRAPPER(8165): blz20_wrp_setsockopt: fd (-1:67), bta -1, rc 0, wflags 0x0, cflags 0x0, port 0 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_setsockopt: configure rfcomm lm mode 0x26, (master:0, auth 1, enc 1) 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_setsockopt: success 01-29 10:22:00.194: D/BLZ20_WRAPPER(8165): blz20_wrp_setsockopt: fd (-1:67), bta -1, rc 0, wflags 0x0, cflags 0x0, port 0 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_setsockopt: configure rfcomm sndbuf len 71680 bytes 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_setsockopt: success 01-29 10:22:00.194: D/BLZ20_ASOCKWRP(8165): asocket_init 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_fcntl: s 67, cmd 3 01-29 10:22:00.194: D/BLZ20_WRAPPER(8165): blz20_wrp_fcntl: fd (-1:67), bta -1, rc 0, wflags 0x0, cflags 0x0, port 0 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_fcntl: s 67, cmd 4 01-29 10:22:00.194: D/BLZ20_WRAPPER(8165): blz20_wrp_fcntl: fd (-1:67), bta -1, rc 0, wflags 0x0, cflags 0x0, port 0 01-29 10:22:00.194: D/BLZ20_WRAPPER(8165): blz20_wrp_fcntl: transparant fcntl 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_fcntl: s 69, cmd 3 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_fcntl: wsock not found, pass through transparantly 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_fcntl: s 69, cmd 4 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_wrp_fcntl: wsock not found, pass through transparantly 01-29 10:22:00.194: I/BLZ20_WRAPPER(8165): blz20_set_asocket: success (67,68,69) 01-29 10:22:00.214: I/BluetoothIF(8165): BEGIN mConnectThread 01-29 10:22:00.234: E/BluetoothIF(8165): TP: IOException error: java.io.IOException: Unable to start Service Discovery 01-29 10:22:00.234: E/BluetoothIF(8165): Unable to start Service Discovery 01-29 10:22:00.234: E/BluetoothIF(8165): Unable to start Service Discovery 01-29 10:22:00.234: D/BluetoothSocket(8165): close(): android.bluetooth.BluetoothSocket@405c8f78 01-29 10:22:00.234: D/BLZ20_ASOCKWRP(8165): asocket_abort [67,68,69] 01-29 10:22:00.234: I/BLZ20_WRAPPER(8165): blz20_wrp_shutdown: s 67, how 2 01-29 10:22:00.234: D/BLZ20_WRAPPER(8165): blz20_wrp_shutdown: fd (-1:67), bta -1, rc 0, wflags 0x0, cflags 0x0, port 0 01-29 10:22:00.234: I/BLZ20_WRAPPER(8165): blz20_wrp_shutdown: shutdown socket 01-29 10:22:00.234: D/BLZ20_WRAPPER(8165): blz20_wrp_write: wrote 1 bytes out of 1 on fd 69 01-29 10:22:00.234: D/BLZ20_ASOCKWRP(8165): asocket_destroy 01-29 10:22:00.234: D/BLZ20_ASOCKWRP(8165): asocket_abort [67,68,69] 01-29 10:22:00.234: I/BLZ20_WRAPPER(8165): blz20_wrp_shutdown: s 67, how 2 01-29 10:22:00.234: D/BLZ20_WRAPPER(8165): blz20_wrp_shutdown: fd (-1:67), bta -1, rc 0, wflags 0x0, cflags 0x0, port 0 01-29 10:22:00.234: I/BLZ20_WRAPPER(8165): blz20_wrp_shutdown: shutdown socket 01-29 10:22:00.234: D/BLZ20_WRAPPER(8165): blz20_wrp_write: wrote 1 bytes out of 1 on fd 69 01-29 10:22:00.234: I/BLZ20_WRAPPER(8165): blz20_wrp_close: s 69 01-29 10:22:00.234: D/BLZ20_WRAPPER(8165): blz20_wrp_close: std close (69) 01-29 10:22:00.244: I/BLZ20_WRAPPER(8165): blz20_wrp_close: s 68 01-29 10:22:00.244: D/BLZ20_WRAPPER(8165): blz20_wrp_close: std close (68) 01-29 10:22:00.244: I/BLZ20_WRAPPER(8165): blz20_wrp_close: s 67 01-29 10:22:00.244: D/BLZ20_WRAPPER(8165): blz20_wrp_close: fd (-1:67), bta -1, rc 0, wflags 0x0, cflags 0x0, port 0 01-29 10:22:00.244: I/BLZ20_WRAPPER(8165): __close_prot_rfcomm: fd 67 01-29 10:22:00.244: I/BTL_IFC(8165): send_ctrl_msg: [BTL_IFC CTRL] send BTLIF_BTS_RFC_CLOSE (BTS) 8 pbytes (hdl 66) 01-29 10:22:00.244: D/BTL_IFC_WRP(8165): wrp_close_s_only: wrp_close_s_only [67] (67:-1) [] 01-29 10:22:00.244: D/BTL_IFC_WRP(8165): wrp_close_s_only: data socket closed 01-29 10:22:00.244: D/BTL_IFC_WRP(8165): wsactive_del: delete wsock 67 from active list [ad40f904] 01-29 10:22:00.244: D/BTL_IFC_WRP(8165): wrp_close_s_only: wsock fully closed, return to pool 01-29 10:22:00.244: D/BLZ20_WRAPPER(8165): btsk_free: success 

Currently, the best way I can see it is to develop my code so that if the .createRfcommSocketToServiceRecord() method immediately crashes with the exception “cannot start detection”, then it will return to the selection method, which until today, I never had to use.

Additional info: My application is targeting API level 8. Suspecting that the RFCOMM connection error affects Android 2.2 and lower, I tried to switch to API level 10 only to see if this would affect the behavior of .createRfcommSocketToServiceRecord() , but the problem continued: attempts to connect to a single Linvor module led to an immediate IOException, as described above.

Thanks - Trev

Answer 1

Fighting the same problem. Using API 10 on 2 phones. Both with Android 4.0.4. One phone constantly fails with "Unable to start opening," but works with reflection. The second phone giving "Permission is stripped" with reflection, but works with createRfcommSocketToServiceRecord ().

And for research, I checked Android sources. So this is not happening in BluetoothSocket.java:

  boolean inProgress = false; try { inProgress = service.fetchRemoteUuids(device.getAddress(), uuid, this); } catch (RemoteException e) {Log.e(TAG, "", e);} if (!inProgress) throw new IOException("Unable to start Service Discovery"); 

But fetchRemoteUuids () has many points of failure and no, they do not throw exceptions, but simply return false. BluetoothService.java:

 public synchronized boolean fetchRemoteUuids(String address, ParcelUuid uuid, IBluetoothCallback callback) { mContext.enforceCallingOrSelfPermission(BLUETOOTH_PERM, "Need BLUETOOTH permission"); if (!BluetoothAdapter.checkBluetoothAddress(address)) { return false; } RemoteService service = new RemoteService(address, uuid); if (uuid != null && mUuidCallbackTracker.get(service) != null) { // An SDP query for this address & uuid is already in progress // Do not add this callback for the uuid return false; } if (mUuidIntentTracker.contains(address)) { // An SDP query for this address is already in progress // Add this uuid onto the in-progress SDP query if (uuid != null) { mUuidCallbackTracker.put(new RemoteService(address, uuid), callback); } return true; } boolean ret; if (getBondState(address) == BluetoothDevice.BOND_BONDED) { String path = getObjectPathFromAddress(address); if (path == null) return false; // Use an empty string for the UUID pattern ret = discoverServicesNative(path, ""); } else { ret = createDeviceNative(address); } mUuidIntentTracker.add(address); if (uuid != null) { mUuidCallbackTracker.put(new RemoteService(address, uuid), callback); } Message message = mHandler.obtainMessage(MESSAGE_UUID_INTENT); message.obj = address; mHandler.sendMessageDelayed(message, UUID_INTENT_DELAY); return ret; } 

Or do native methods fail, which leads us to drivers? Or the “uuid is already running” part fails because I don’t even see an attempt to connect / scan uuid, just instantly getting an exception.

Answer 2

Linvor 1.8 is here.
I struggle a lot with this device. Your specific problem is one of the problems that I have encountered.
It can be solved by pulling the reset contact (move the pin to GND using the jumper) when the device is fully turned on.
The reset pin is the 3rd pin on the bottom left of the device.
For me, this will allow me to connect to the device once without reflection, but it may again return to bad behavior.
My suggestion is that you implement a watchdog timer from android to the device and run the reset command with the remaining GPIO output when the timer is reached.
As for the cause and what caused the behavior. I still don’t know, but I hope someone finds out.

My suspect is that the device is stuck in an unknown state.