Android蓝牙LE通知存在问题

我正在尝试编写一个蓝牙LE应用程序来访问Zephyr HxM智能心脏监护仪。这个显示器有几个蓝牙服务，但我对电池服务、心率服务和具有活动和峰值加速度的自定义服务感兴趣。电池电量（BAT）、心率测量（HR）和自定义测量（CUS）各有一个特性。HxM大约每秒更新一次

我正在用Android 4.4的Galaxy S4做这件事

它没有按照文档中的预期工作

我最初的做法是：

Read BAT
Set notification for HR 
Set notification for CUS.

然后等待回调。设置通知意味着调用

BluetoothGatt.setCharacteristicNotification(Characteristic char , boolean enabled)

（人们也可以为BAT做通知，但是规范不要求支持。然而，HxM确实支持它。）

这不管用。我收到了人力资源部的BAT和通知，但没有收到CUS。如果我取消了第二步，我会收到CUS的通知。我两个都得不到。（这表明我正确读取了特征，因此这[可能]不是问题所在。）

我发现一些迹象表明Android的蓝牙协议栈在同步方面存在问题，但是没有硬文档。然后我尝试了以下方法：

Read BAT.
Wait for the BAT reading, then set notification for HR,
Get HR, then disable notification for HR, and start notification for CUS.
Get CUS, then disable notification for CUS, and start notification for HR.
And continue to loop.

我有球棒，就这些

通过反复试验，我发现了以下工作：

Read BAT.
Wait for the BAT reading, then set notification for HR,
Get HR, then start notification for CUS.
Get CUS, then start notification for HR.
And continue to loop.

（同上，但不禁用通知。）通常情况下，我会得到一个HR读数，然后在200毫秒内得到CUS读数。可以假设它们来自同一个更新。（数据中没有时间戳，必须保持较短的时间戳才能显示出来。）事实上，逻辑更复杂，因为如果预期的读数没有出现，计时器是必要的。这个逻辑比我的第一次尝试要复杂得多（而且更容易出错），文档似乎认为这是正确的

我已经联系了Zephyr，他们说HxM Smart已经在Windows上进行了广泛的测试，并将按照它应该做的同时通知。也有迹象表明，它在iOS上也能正常工作

还有一个问题我不明白。为了获得通知，您必须在本地为通知启用以下特征：

BluetoothGattDescriptor descriptor = characteristic
        .getDescriptor(UUID_CLIENT_CHARACTERISTIC_CONFIG);
resSet = descriptor.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE);
resWrite = mBluetoothGatt.writeDescriptor(descriptor);

这是每个特征的设置，当第一次收到特征时，只需执行一次。相反，我发现每次设置通知时都必须这样做。这有可能只是造成了足够的时间延迟，事情才能正常进行。我不知道。这种反复试验占用了我很多时间。如果能对它的工作原理有一个明确的说明，那就太好了

我应该注意，对于所有返回结果的调用，结果都是true（success）

我为冗长的声明道歉。我的问题是:

我没有发现我必须执行所述操作的文档。所有迹象表明您已设置通知并等待回调是否有文档，或者这是一个错误，或者只是一个糟糕的实现？（或者是我的错误？）我特别想知道我必须做的事情的文档在哪里

其次，还有一个更复杂的问题。我试着调试这些例程，看看代码实际上在做什么。当我访问BluetoothGatt.class时，源代码行与调试堆栈所说的不匹配。因此，我假设S4没有使用标准Android。我不知道从那以后该怎么办。这是令人沮丧的，虽然我有一些似乎有效的东西，但它是困难的，几乎可以肯定不那么强大

---

谢谢你的帮助。

我也遇到过同样的问题，在顺序中写入多个值，在它们之间放置一个线程。睡眠（200）解决了这个问题（唉，我应该说）。也许这也有助于获得通知。

---

在Nexus5上的android 4.4.2上进行了测试。不，4.4并不能解决所有问题

Im可能已经很晚了，但您应该实现一个队列体系结构，用于设置发送通知的特征。我在文章中使用了与miznick类似的技术，最后只为本机BLE堆栈编写了包装器代码，因为我有几个应用程序使用BLE。从那以后，我再也没有收到通知的问题。我同意你的观点，Android BLE文档应该有一些关于BLE堆栈不同步的信息或警告。坦白地说，我认为应该重新编写它来处理同步写入调用，并将它们排队。

首先，您可以为第一个特征设置通知（即setCharacteristicNotification和set Descriptor）

---

并且，在onDescriptorWrite回调函数中为第二个特征设置通知。

好问题。我有一个类似的问题，我必须通过通报听取两个特征，然后写信给第三个特征。无法在android上正常运行，但在ios上运行良好。如果有机会的话，我建议你在另一款（品牌）android设备上试用。即使在4.4.4上，BLE仍然不稳定，很多事情都不如预期的那样工作，缺乏文档，并且在不同的移动设备上仍然会给出不同的结果。您应该能够启用通知，并且只接收它们，而无需继续做任何进一步的事。要意识到的是，一次只能执行一个后端操作，如writeDescriptor。如果一个请求仍在进行中，而您尝试执行另一个请求，那么它将忽略新请求。这一点没有很好的记录，是一种痛苦。您必须建立某种形式的排队方法，请参见Ifor，谢谢。我想我的问题不是等待writeDescriptor。这里还有一篇文章，但它没有考虑通知。根据您所说，我不必担心它们（在使用writeDescriptor正确启用它们之后）。我不在电脑旁，但我一回来就会试试这个。再次感谢。我确实为writeDescriptor实现了队列