Android 蓝牙 LE - BluetoothGatt - onNotify 停止接收数据

Question

我正在连接到蓝牙 LE 外围设备作为中心。我正在将数据写入特征，并通过通知以 20 字节为单位接收数据。

通知订阅:

private void setCharacteristicNotification(BluetoothGattCharacteristic characteristic, boolean enabled) {
    if (mBluetoothAdapter == null || mBluetoothGatt == null) {
        Log.w("BluetoothAdapter not initialized");
        return;
    }

    Log.d("Enabling Notifications");

    mBluetoothGatt.setCharacteristicNotification(characteristic, enabled);

    BluetoothGattDescriptor descriptor =
            characteristic.getDescriptor(UUID.fromString(CLIENT_CHARACTERISTIC_CONFIG));

    descriptor.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE);

    mBluetoothGatt.writeDescriptor(descriptor);
}

如果在写入之间只需要接收少量 block ，则此方法工作正常。蓝牙堆栈为每个 block 发送通知:

D/BluetoothGatt﹕ onNotify() - Device=B0:EC:8F:00:07:AA UUID=06d1e5e7-79ad-4a71-8faa-373789f7d93c

但是如果写入之间的 block 数大于大约 10，堆栈将停止通知并且其余数据将丢失!该设备肯定会发送更多数据，因为我们可以在 iOS 设备上接收它。

接收到的通知数量因 Android 设备而异。 Galaxy S3 (4.3) 收到 5，nexus 5 (4.4.4) 和 htc one (4.4.2) 收到 12。

BT 堆栈在最后一次通知后 30 秒关闭连接。

D/BluetoothGatt﹕ onClientConnectionState() - status=0 clientIf=5 device=B0:EC:8F:00:00:88

有人可以重现这个问题吗？

由于蓝牙 LE 堆栈是基于轮询的，我猜堆栈出于某种原因停止从外围设备轮询数据。目标设备不支持指示。

更新:Android L 蓝牙堆栈提供的附加信息:

06-27 12:20:02.982 18909-18946/? D/BtGatt.GattService﹕ onNotify() - address=B0:EC:8F:00:01:09, charUuid=06d1e5e7-79ad-4a71-8faa-373789f7d93c, length=20

06-27 12:20:07.666 18909-18984/? E/BTLD:############################################## ########################06-27 12:20:07.666 18909-18984/? E/BTLD﹕#06-27 12:20:07.666 18909-18984/? E/BTLD:# 警告:BTU HCI(id=0) 命令超时。操作码=0xfd5506-27 12:20:07.666 18909-18984/? E/BTLD﹕#06-27 12:20:07.666 18909-18984/? E/BTLD:############################################## ########################06-27 12:20:07.670 18909-18984/? E/bt-btm:无法解释IRK VSC cmpl回调06-27 12:20:07.670 18909-18984/? w/bt-hci:HCI Cmd超时计数器106-27 12:20:34.315 18909-18984/? E/bt-btm:btm_sec_disconnected - 清除挂起标志

Answer 1

也许不是一个理想的解决方案，但我已经开始接受通知根本不起作用或停止工作作为在 Android 上执行 BLE 的不幸现实。考虑到这一点，我相信最好是在正常通知被破坏时通过执行读取轮询来设置自己的“伪通知”备份机制。例如，在 Handler#postDelayed() 中每秒循环一次。您甚至可以将其抽象到一个单独的类后面，该类存储最后读取的值，并且仅在最后读取的值不等于新值时通知您的 UI。