本机Android BLE实现本质上是同步的吗?

One*_*rld 15 android bluetooth-lowenergy gatt android-4.3-jelly-bean

我记得在三星BLE API(存档页面)"指南和提示" -doc中阅读:

三星F/W和堆栈最重要的概念之一是它的同步特性.也就是说,如果我们调用例如 writeCharacteristic某个特定的特性,如果它返回 true,则在收到回调后应该对any BluetoothGattBluetoothGattServer方法进行下一次调用onCharacteristicRead.这是因为堆栈被设计为一次仅支持和处理一个GATT调用,例如,如果您在第一个调用之后很快调用 writeCharacteristicreadCharacteristic处理任何特性,则忽略它.

  1. 这也适用于Android 4.3中引入的BLE的nativ实现吗?
  2. Samsung API一次只支持一个连接的GATT设备.这在原生API中有变化吗?

One*_*rld 17

三星最近在我在我的问题中链接的同一页面上发布了一个"迁移"文档.他们在将新的原生BLE API与Samsung BLE API进行比较时完全回答了我的问题:

堆栈和F/W的同步性质未受影响.也就是说,如果我们调用例如,writeCharacteristic对于特定的特性,如果它返回true,则应在收到回调之后对any BluetoothGattBluetoothGattServer方法进行下一次调用onCharacteristicRead.这是因为堆栈设计同时支持和进程只有一个关贸总协定电话,如果,例如,你打电话writeCharacteristic或者readCharacteristic任何characteristic的第一个后不久,它将被忽略.

  • 任何人都可以确认android.bluetooth.BluetoothGatt是否只能处理一个待处理的GATT操作**每个设备**,**每个进程**,或**周期**(即:跨所有进程).我认为它是PER DEVICE,但是这个问题是如此糟糕,以至于如果不是这样我就不会感到惊讶.如果限制只是PER DEVICE,那么能够处理多个同时操作的操作系统/设备是冒烟的证据,这个问题纯粹是由于蓝牙适应器实例中的一些弱的天真实现,操作系统处理每个进程(我假设是所有流程中的单例). (3认同)
  • 嗯,这是一个明显的错字。您在写入请求后等待写入响应。您在写入请求后不需要等待读取响应...... (2认同)