Android Bluetooth LE - BluetoothGatt - onNotify stops receiving data

Question

I am connecting to a Bluetooth LE peripheral as a central. I am writing data to a characteristic and I receive data through Notifications in chunks of 20 bytes.

Notification subscription:

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);
}

This works fine if only small number of chunks need to be received between writes. The bluetooth stack sends notifications for each chunk:

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

But if the number of chunks between writes is bigger than about 10, the stack stops the notifications and the rest of the data is lost! The device is definitely sending more data, as we can receive it on iOS devices.

The number of received notifications varies between android devices. A Galaxy S3 (4.3) receives 5, a nexus 5 (4.4.4) and a htc one (4.4.2) receive 12.

The BT stack closes the connection 30 seconds after the last notification.

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

Can anybody reproduce this issue?

As the Bluetooth LE stack is polling based, I guess that the stack stops polling data from the peripheral for some reason. The target device does not support indications.

Update: Additional Information provided by the Android L bluetooths stack:

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﹕ # WARNING : BTU HCI(id=0) command timeout. opcode=0xfd55 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.670 18909-18984/? E/bt-btm﹕ can not interpret IRK VSC cmpl callback 06-27 12:20:07.670 18909-18984/? W/bt-hci﹕ HCI Cmd timeout counter 1 06-27 12:20:34.315 18909-18984/? E/bt-btm﹕ btm_sec_disconnected - Clearing Pending flag

Answer 1

Maybe not an ideal solution, but I've come to accept notifications not working at all or stopping working as an unfortunate reality of doing BLE on Android. With this is in mind, I believe it's best if you set up your own "pseudo-notification" backup mechanism by doing a read poll when it appears normal notifications are broken. For example, in a Handler#postDelayed() loop once a second. You can even abstract it away behind a separate class that stores the last read value and only notifies your UI when the last read value doesn't equal the new value.