16

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 returns true, the next call to any BluetoothGatt or BluetoothGattServer method should be done after the onCharacteristicRead 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 call writeCharacteristic or readCharacteristic on any characteristic soon after the first one, it is ignored.

  1. Does that also apply to the native implementation of BLE introduced in Android 4.3?
  2. Samsung API also supports only one connected GATT device at a time. Has this changed in the native API?
stkent
  • 19,772
  • 14
  • 85
  • 111
OneWorld
  • 17,512
  • 21
  • 86
  • 136
  • There's an ongoing thread related to the synchronous nature of the API on Google's issue tracker: https://code.google.com/p/android/issues/detail?id=58381 – Ash Eldritch Jan 07 '14 at 12:04
  • I've just implemented a queue for all writes and this seems to be working well so far. – Ash Eldritch Jan 08 '14 at 07:05
  • 1
    @Ash According to the docs provided by SAMSUNG, the behavoir isn't limited to write operations. Yes, using a queue is a common way to solve that problem. 'working well so far': It's hard to test and reproduce the cancelling of a command by another. Often times you will encounter problems once your BLE code gets more complex, because you do more stuff based on previous calls. I only do the next BLE operation after the one before finished (received answer) or after the one before failed to finished in an appropriate time. By the way, your comments would suit better as an answer to this question. – OneWorld Jan 08 '14 at 09:16
  • @Ash can you share your implementation ? – Ewoks Apr 29 '15 at 22:10
  • 2
    @Ewoks https://gist.github.com/SoulAuctioneer/ee4cb9bc0b3785bbdd51 – Ash Eldritch May 01 '15 at 16:55
  • Thanks a lot.. :) in the mean time i implemented as well but it is useful to see your solution. Did i understand good that you are queueing reading characteristics as well? – Ewoks May 04 '15 at 23:35

2 Answers2

20

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 any BluetoothGatt or BluetoothGattServer method should be done after the onCharacteristicRead 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 call writeCharacteristic or readCharacteristic of any characteristic soon after the first one, it is ignored.

OneWorld
  • 17,512
  • 21
  • 86
  • 136
  • 1
    I'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. – svens Nov 15 '13 at 17:50
  • 4
    Can 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). – swooby Mar 22 '16 at 00:57
  • 1
    It is one pending operation per BluetoothGatt object. – Emil Sep 10 '17 at 20:20
  • @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. – OneWorld Nov 03 '17 at 15:35
  • 2
    Well 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... – Emil Nov 03 '17 at 16:56
  • It would be nice to know the title or where to find this "migration document". PS @Emil was right, its an obvious typo that deserves correction. – axa Jan 16 '23 at 06:35
  • @axa: See http://web.archive.org/web/20150315083715/http://developer.samsung.com/ble, section "Download Links". The document itself appears not to be archived :( – OneWorld Jan 19 '23 at 09:17
  • @axa: [I uploaded for your the resources Samsung provided developers once Samsung BLE SDK Beta was new and hot :)](https://drive.google.com/drive/folders/1fuBcDDUtCZcw9l2WdhEME0g2t1kU5Ab6?usp=share_link) The "Guide_and_Hints_for_Samsung_BLE_API.pdf" document includes almost the same sentence if you search for "That is, if we call". The migration document came later once Android 4.3 was published and when there was no need anymore to use Samsung Ble SDK Beta, if one had not to support Android 4.2.2 devices – OneWorld Jan 19 '23 at 09:34
  • @axa: To my suprise, [Guide_and_Hints_for_Samsung_BLE_API.pdf is still online](https://img-developer.samsung.com/contents/authCdn/ble/Guide_and_Hints_for_Samsung_BLE_API.pdf?__gda__=1375430976_5fccae8604db7eb9b442186689e3381d). It is linked [in that question](https://itecnote.com/tecnote/android-is-the-native-android-ble-implementation-synchronous-in-nature/). – OneWorld Jan 19 '23 at 09:39
  • @OneWorld Tuché. didnt think to check for links though. ive been chewed out for adding links in SO sighting broken links. i think there is a place for links though. – axa Jan 21 '23 at 15:27
-2
  1. No. most of the function calls are asynchronous.
  2. I don't know. Official docs doesn't mention it but it doesn't say that it supports only one device either. I believe it's possible to do it. Check this article: http://blog.lemberg.co.uk/getting-bottom-android-bluetooth-low-energy-api#.UfvK6ZK-1cY

It says (I don't know what its source is) that multiple peripheral devices can connect to one Android Central device

edoardotognoni
  • 2,752
  • 3
  • 22
  • 31
  • 1
    The 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. – OneWorld Aug 03 '13 at 15:34
  • Ah 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. – edoardotognoni Aug 04 '13 at 13:33