只有一个特定的蓝牙SPP模块，.createRfcommSocketToServiceRecord()突然不再工作了，但是反射方法起作用了

Question

我的应用程序通过建立和处理连接到蓝牙SPP模块，这与Android蓝牙文档中所描述的基本相同。也就是说，在我的连接线程中，我已经习惯于简单地使用：

socket = device.createRfcommSocketToServiceRecord(MY_UUID)

其中UUID为“知名”SPP UUID，00001101-0000-1000-8000-00805F9B34FB。

我连接的蓝牙设备是小型蓝牙/串行适配器。我已经用了三个来做测试。其中两个是"Linvor“蓝牙到TTL级的串行多氯联苯，目前在eBay上都是相同的；第三个是制造商未知的完全封闭的适配器。

在我开发这个应用程序的过程中，我经常在各种设备上进行测试，从AndroidVersion2.2.1(我以前的Archos 101)到Archos蜂窝设备。我一直在测试的设备主要是我想要的高清设备，它目前的Android版本为2.3.5。在这一年左右的时间里，我可以自信地说，我从来没有遇到过任何连接问题。

昨天，在我的愿望HD (2.3.5)测试期间，我发现应用程序将不再连接到我的Linvor蓝牙PCB，我最近一直在工作。在使用上面引用的代码行获得套接字之后，在尝试socket.connect()时，我将立即获得一个IOException of Unable to start discovery。

我做的下一件事是交换到我的另一个备用Linvor模块，并尝试配对和连接。应用程序连接得很好。然后，我还交换了我的第三个打包的蓝牙适配器，应用程序也连接到了这个适配器上。回到我的第一个Linvor模块，应用程序仍然拒绝连接。我确保我取消‘故障’的设备在我的愿望高清，关闭蓝牙，关闭手机，删除和重新插入电池，断电，重新对等，然后再试一次。应用程序仍然拒绝连接到第一个Linvor模块，但是可以很好地连接到第二个Linvor模块和其他适配器模块。

然后，我拿起我的Archos 101 (2.2.1)，启动我的应用程序的一个更老的版本，这个版本仍然安装在它上。Archos 101立即连接到“故障”的Linvor模块很好。

此时，我开始怀疑这两种设备--也就是我的愿望HD，或者更有可能是Linvor模块--是否会在其闪存表中为成对设备设置一些损坏的条目。换句话说，第一个Linvor模块中的一些东西意味着它不再接受来自我的愿望HD的连接(尽管它确实接受一个配对)，但它仍然将接受来自其他设备的连接；同时，我的愿望HD也可以像往常一样愉快地连接到其他设备，包括其他备用Linvor模块。

经过几个小时的绞尽脑汁和绝望之后，我决定试试如Michael在这里的回答所描述的反射连接方法.这是我经常听说的事情，我的印象是它适用于Android2.2和更低的版本。然而，在我从各种安卓设备上使用蓝牙SPP的整整一年里，我从来不需要使用它，因为.createRfcommSocketToServiceRecord()一直在为我工作。因此，我使用迈克尔对这个问题的回答中给出的代码来创建我的socket，而令我惊讶的是，我的愿望HD连接到“错误的”Linvor模块。

所以回顾一下，情况似乎是这样的：

在过去的一年里，我经常在2.2.1和2.3.5设备上使用.createRfcommSocketToServiceRecord()连接到我的三个蓝牙SPP适配器。

然后，有一天，在没有对手机或蓝牙适配器上的软件进行任何更改的情况下，第一个适配器突然需要反射连接才能工作；另外两个适配器(其中一个与第一个适配器的类型相同)继续使用.createRfcommSocketToServiceRecord()与我的应用程序连接得很好。请注意，在此行为突然改变之前，我的蓝牙代码绝对没有发生任何更改。

这到底是怎么回事？

有谁能告诉我什么是Android版本级别的反射‘黑客’不应该是必需的？我的印象是，它不应该再是必要的，比如说2.3.5 (我的愿望是HD)。对吗？

是否.createRfcommSocketToServiceRecord()错误的本质是连接通常会正常工作，但有时不工作取决于月亮的阶段？

下面是使用.createRfcommSocketToServiceRecord()时，当连接与特定Linvor模块连接失败时产生的Logcat输出

​

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, mViews2: 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

​

目前，我看到的最佳操作方法是设计我的代码，以便如果.createRfcommSocketToServiceRecord()方法立即失败，并出现“无法开始发现”异常，那么回到到目前为止我从未使用过的相关方法。

更多信息:我的应用程序目标API级别8。我怀疑RFCOMM连接错误会影响Android2.2及以下版本，所以我尝试切换到above 10，看看它是否会对.createRfcommSocketToServiceRecord()的行为产生任何影响，但问题依然存在:尝试连接到one Linvor模块会导致立即出现IOException，如上所述。

谢谢-崔佛

Answer 1

同样的问题。在2部手机上使用API 10。这两款手机都配有Android4.0.4。一部手机不断地失败，“无法开始发现”，但却在思考中工作。第二个电话给“许可被拒绝”与反射，但工作与createRfcommSocketToServiceRecord()。

为了进行研究，我查了一下安卓的资料来源。因此，它在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");

但是fetchRemoteUuids()有很多失败点，而不是，它们不会抛出异常，只返回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;
}

任何一种本地方法都失败了，这导致我们找到驱动程序？或者"uuid已经在进行中“部分失败了，因为我甚至没有看到连接/扫描uuid的尝试，只是立即得到异常。

Answer 2

这里是1.8度。

我经常和这个装置斗争。你的特殊问题是我遇到的问题之一。

当设备完全供电时，可以通过拉下复位销(跳线跳转到GND )来解决这个问题。

复位引脚是设备左下角的第三个引脚。

对我来说，这将允许我在没有反射的情况下连接到设备一次，但它可能会再次回到不良行为。

我的建议是，您可以实现从android到设备的看门狗ping，并在计时器到达时用剩余的GPIO引脚触发重置命令。

为什么和是什么引发了这种行为。我还是不知道，但希望有人能搞清楚。

我的嫌疑人是这个装置卡在一个未知的状态。

​