BluetoothPeripheralManager is incorrectly chopping long value

[ceduliocezar]

TLDR; BluetoothPeripheralManager seems to be incorrectly chopping long values when BluetoothDevice.TRANSPORT_BREDR is used as transport. If BluetoothDevice.TRANSPORT_LE is used the long read works fine .

I ran several tests locally with two android phones and an iphone(central role). My observation is that when BluetoothDevice.TRANSPORT_BREDR is used the OS stack does not issue subsequent calls incrementing the offset. Both Android OS and iOS have this behavior.

The problem seems to be on BluetoothPeripheralManager.

Scenario

• Android PhoneA runs peripheral server with blessed-android.
• Android PhoneB runs central with blessed-android.

Steps to reproduce the problem:

• Android PhoneA runs Peripheral role with 1 service and 1 characteristic with long value ( it has to be longer that default mtu size)

val characteristic = BluetoothGattCharacteristic(CHARACTERISTIC_ID, BluetoothGattCharacteristic.PROPERTY_READ, BluetoothGattCharacteristic.PERMISSION_READ_ENCRYPTED)

characteristic.value = "Lorem ipsum dolor sit amet, consectetur adipiscing elit".toByteArray() 

• Android PhoneB connects to PhoneA peripheral using BluetoothDevice.TRANSPORT_BREDR.
• Service discovery happens.
• PhoneB issues a read request to characteristic.
• PhoneA responds to the request chopping the end of the byte array.
• PhoneB receives part of the byte.

_{Legal Imprint (Mandatory for legal reasons, sorry for that) Cedulio Silva cedulio.silva@daimler.com, MBition GmbH, imprint}

[ceduliocezar]

With all that being said, my understanding is that should take care of chopping the beginning of the array based on the offset value and return the rest of the bytes. The end of the array is chopped on OS level.

I'm working on the fix and I will create a PR as soon I write the tests.

[ceduliocezar]

PR created https://github.com/weliem/blessed-android/pull/130

[weliem]

Merged PR and released version 2.1.4

I wonder if the same issue also occurs when doing long reads on descriptors.....because that uses the same implementation.

[ceduliocezar]

@weliem I did some testing reading long descriptor values and indeed it has the same problem when BREDR is used.

[weliem]

Ok, applied the same fix to descriptors in release 2.1.5.

Can you test and confirm it now also works for descriptors?