蓝牙低功耗通知

Question

我正在尝试从健康档案中读取温度值。健康体温计服务。根据Google官方BLE开发页面，当我尝试通知一个健康体温计特征以读取温度时，我尝试使用writeDescriptor写入描述符值（客户端特征配置）。writeDescriptor的回调方法返回状态5，根据Google，这是GATT_INSUFFICIENT_AUTHENTICATION。 所以我注释了writedescriptor的代码，并尝试调用mBluetoothGatt.setCharacteristicNotification(characteristic, enabled)方法，但onCharacteristicChanged方法从未被调用。当我与我的iOS开发团队交谈时，他们说他们从未写过描述符值，他们只是将通知设置为true，并从同一芯片获取温度值。 对于Android开发人员来说，编写描述符值是否有必要才能获得通知？最后，我尝试运行来自bluetooth.com网站的官方蓝牙应用进行测试目的，他们只禁用了所有三个按钮的通知读取和写入吗？ 感谢您，对我的英语表示抱歉。 [更新]
找到一些日志可能会导致一些绑定问题，请帮助我解决。

• 短期密钥生成仍然记录为错误
  11-08 11:26:44.392: E/bt-smp(1014): STK Generated

• 之后，绑定状态发生了巨大变化，可能导致不足的身份验证
  11-08 11:26:49.437: I/BluetoothBondStateMachine(1014): bondStateChangeCallback: Status: 0 Address: 00:16:A4:C0:FF:EE newState: 2
  11-08 11:26:49.437: D/BtGatt.btif(1014): btif_gattc_upstreams_evt: Event 9
  11-08 11:26:49.437: E/BluetoothBondStateMachine(1014): In stable state, received invalid newState: 12

[更新]
在Nexus 7上升级为KitKat 4.4后，添加了两个方法
device.createBond();
device.setPairingConfirmation(true);
现在可以读取加密特征，但仍不稳定。但我有一些成功。

- mcd

Answer 1

是的，在Android中启用BLE通知，你必须调用mBluetoothGatt.setCharacteristicNotification(characteristic, enabled)并写入适当的值到该特征的描述符0x2902。

我不确定为什么你会收到GATT_INSUFFICIENT_AUTHENTICATION错误，这可能是体温计实现引起的。

编辑： 根据评论中提供的新信息和屏幕截图，有几个需要检查的事项：

1. 特征是指示特征，而不是通知特征。你将写入描述符的值应该是BluetoothGattDescriptor.ENABLE_INDICATION_VALUE，而不是BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE。请注意，你仍然需要通过setCharacteristicNotification()打开指示。（术语有些混乱，但根据文档是必要的）

2. 对于不稳定的Android蓝牙堆栈，请尝试重启蓝牙，并关闭WiFi。这将增加稳定性。（虽然不能完全解决问题）

- reTs

---

谢谢您的回复，但是为什么iOS开发人员可以在不设置描述符值的情况下获取温度值，只需将通知设置为true？因此，我们必须为体温计硬件创建两个不同的固件，一个用于iOS，另一个用于Android吗？ - mcd

@mcd 你不需要创建两个不同的固件。相同的温度计将在Android和iOS中均可使用，但在Android应用程序中，您需要进行额外的调用以编写描述符才能使其正常工作。我的猜测实际上是iOS也会写入描述符，但当设置通知为true时，iOS会自动执行此操作。 - reTs

如果read方法返回false，可能有很多可能的原因。我建议您首先检查特征的属性，看看它是否可读。 - reTs

你的检查有误。应该是 (property & PROPERTY_READ) 或/和 (permission & PERMISSION_READ)。 - reTs

读取属性也不可用，权限也不可用，甚至通知属性也不可用。iOS如何获取特征？ - mcd

Answer 2

在我的情况下，问题是BluetoothGatt对象只能接受一个挂起的操作。解决方案是按顺序执行读/写操作，在请求第二个读/写操作之前等待第一个操作完成回调。

- madabrowski