Skip to content
This repository has been archived by the owner on Aug 1, 2023. It is now read-only.

Fix long GATT read operations #87

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

beaufortfrancois
Copy link
Member

We should not return an invalid offset when performing read GATT operations if it needs multiple reading due to a small MTU size (Mac)

Background: https://bugs.chromium.org/p/chromium/issues/detail?id=711286

R: @g-ortuno

if (offset != 0) {
mGattServer.sendResponse(device, requestId, BluetoothGatt.GATT_INVALID_OFFSET, offset,
/* value (optional) */ null);
mGattServer.sendResponse(device, requestId, BluetoothGatt.GATT_SUCCESS, offset,
Copy link
Contributor

@g-ortuno g-ortuno Apr 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of questions:

  1. Since we are using value.length chances are we are sending more bytes than necessary, could we fix that? If not then please comment why we use the length.
  2. I'm somewhat surprised of how we are using the API. I would have guessed that offset would indicate the Android API to only send the data starting from offset. The fact that we 1. send offset back and 2. only send part of the value is making me really suspicious. Could you confirm that simply removing this if statement isn't enough to fix the issue? If it's not enough then I think we can just make that the default behavior:
Log.d(TAG, "Value: " + Arrays.toString(value));
mGattServer.sendResponse(device, requestId, BluetoothGatt.GATT_SUCCESS, offset,
      // TODO: Comment why we use value.length
      Arrays.copyOfRange(value, offset, value.length)); 

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants