BluetoothGatt.writeDescriptor()它返回false.
我没有在文档中找到任何关于此功能的限制说明.但堆栈溢出的ppl说我需要等待BluetoothGattCallback.onDescriptorWrite()才能尝试写另一个描述符.
这里有一个回复说BLE is busy用writeDescriptor()而不能写其他的.
这里是another thread说你不能再调用writeCharacteristic()两次.
我的问题是
>这是真的吗？
>是否真的缺少一些用于序列化BLE请求的内部android API缓冲区,并且每个开发人员都必须自己完成它？
>对于不同的功能是否属实？例如,当我调用writeDescriptor()时,我知道在收到onDescriptorWrite()之前我不能再次调用writeDescriptor().但是当我想调用writeCharacteristic()时,我是否必须等待onDescriptorWrite()？
>此外,如果存在功能间依赖性,那么还有哪些功能具有此限制(即：readCharacteristic(),readDescriptor(),requestMtu()…)？
>此外,BluetoothGattServer和BluetoothGatt之间存在相互依赖关系.所以例如当我调用BluetoothGattServer.notifyCharacteristicChanged()时,我应该等待BluetoothGattServerCallback.onNotificationSent才能调用BluetoothGatt.writeDescriptor()或BluetoothGatt.writeCharacteristic()吗？ (顺便说一下,关于NotificationSent()的谷歌文档的赞美是运气得当.文件说：
When multiple notifications are to be sent, an application must wait
for this callback to be received before sending additional
notifications.
>最后提出所有这些问题 – 我觉得Android BLE API的记录不足.或者我错了,并且在某处记录了允许调用序列的方法？如果是,请指点我这样的文件？如果不是有一些渠道,我们可以打开谷歌的问题,并要求他们添加到文档的东西？我的意思是它可能不是很多文本 – 像onNotificationSent()这样的函数是正确记录的.他们只需要将这句话复制到其他功能.
文档缺乏信息.但是,您可以阅读源代码以找出规则,其中(当前)如下：对于每个BluetoothGatt对象,您一次只能有一个未完成的请求,包括requestMtu,readCharacteristic,writeCharacteristic,readDescriptor,writeDescriptor和executeReliableWrite.因此,如果发出读取请求,则需要在发出写入请求之前等待读取响应.虽然他们实现了在BluetoothGatt.java中有持续操作时返回false的代码,但是他们忘记为requestMtu执行此操作,因此如果您在requestMtu就是其中之一时有多个请求,您迟早会得到随机错误(在这篇文章的最新版本).
所以,是的,每个开发人员都必须手动序列化请求.请注意,蓝牙堆栈实际上有一个请求队列,但它仅限于每个客户端只有一个请求(即BluetoothGatt对象).因此,如果同一电话上的两个应用同时与同一设备通话,您将永远不会出现“忙碌”错误.唯一的例外是如果你使用Write Without Response,那么当前的数据流实现是非常错误的(参见https://issuetracker.google.com/issues/37121017,谷歌似乎已经忽略了).
您可以在编写特征的同时发送通知,因为服务器和客户端角色是分开的.
关于更新文档,你总是可以尝试在https://issuetracker.google.com提交一个问题(但我感觉没有人读到它),或者,因为Android是开源的,所以发送一个拉取请求到https://android-review.googlesource.com/,它更新生成文档的Javadoc .