Is the native Android BLE implementation synchronous in nature?
Samsung recently published a "migration"-document on the same page I linked in my question. They exactly answer my question while comparing the new native BLE API with the Samsung BLE API:
The synchronous nature of the stack and F/W hasn’t been affected. That is, if we call for example,
writeCharacteristic
for a particular characteristic, if it returns true, the next call to anyBluetoothGatt
orBluetoothGattServer
method should be done after theonCharacteristicRead
callback is received. This is because the stack is designed to support and process only one GATT call at a time, and if, for example, you callwriteCharacteristic
orreadCharacteristic
of anycharacteristic
soon after the first one, it is ignored.
OneWorld
Updated on June 26, 2022Comments
-
OneWorld about 2 years
I remember reading in the "Guide and Hint"-doc to the Samsung BLE API (archived page):
One of the most important concepts of the Samsung F/W and stack is its synchronous nature. That is, if we call for example,
writeCharacteristic
for a particular characteristic, if it returnstrue
, the next call to anyBluetoothGatt
orBluetoothGattServer
method should be done after theonCharacteristicRead
callback is received. This is because the stack is designed to support and process only one GATT call at a time, and if, for example, you callwriteCharacteristic
orreadCharacteristic
on any characteristic soon after the first one, it is ignored.- Does that also apply to the native implementation of BLE introduced in Android 4.3?
- Samsung API also supports only one connected GATT device at a time. Has this changed in the native API?
-
OneWorld almost 11 yearsThe Samsung ble API is also asynchronous in some way. You get the answer in a callback (the API is very similar by the way) However, if you fire 2 requests in short time While the first one isn't fully progressed, the first one may get cancelled. So the question is, if the native API has this behavior also.
-
edoardotognoni almost 11 yearsAh ok, now I understand. I don't know if the native APIs follow this behavior. I think so. If you fire 2 scanBLE, the previous one get cancelled, but I'm not sure of that.
-
svens over 10 yearsI'm really glad I found this question. Google doesn't go out of its way to make that clear. Returning true when a read/write request is in fact ignored is quite confusing.
-
swooby over 8 yearsCan anyone confirm if android.bluetooth.BluetoothGatt can only handle one pending GATT operation PER DEVICE, PER PROCESS, or PERIOD (ie: across all processes). I presume it is PER DEVICE, but this problem is so mucked up that it wouldn't surprise me if it was otherwise. If the limitation is only PER DEVICE, then the OS/Device able to handle multiple simultaneous operations is smoking gun proof that this problem is purely due to some weak naive implementation in the BluetoothAdapter instance that the OS hands each process (that I had assumed was a singleton across all processes).
-
Emil almost 7 yearsIt is one pending operation per BluetoothGatt object.
-
OneWorld over 6 years@Emil I just rolled back your change on that question. Please don't modify the quote of the samsung engineers. If you have issues with its content, then please add that as comment.
-
Emil over 6 yearsWell it was an obvious typo. You wait for the write response after a write request. You don't wait for a read response after a write request...