我在TI cc2650上开发了一个Android应用程序和另一个应用程序。 它是一个BLE应用程序。 在这个应用程序中，SP充当中央设备，CC2650充当外围设备。
一开始，在发现服务并订阅我从cc2650读取值的特征后，在android端，我打电话给 requestMtu(myDesiredNewMtu) ，之后cc2650响应事件 ATT_MtuUpdatedEvt 与协商的MTU，然后在机器人方面，我在 {{1}获得回调 onMtuChanged() ，具有最终的MTU值和状态（通常是成功的）。
但是对于目前的情况，我希望CC2650能够开始MTU协商。所以我从CC2650 BluetoothGattCallback 发送了所需的MTU，结果是android响应了＃34;好的新MTU好了，让我们用它吧（ ATT_ExchangeMTURsp 与协商的MTU）＆＃34;但是后来机器人 ATT_ExchangeMTUReq 上的callback没有被调用！
所以我不知道最终协商的MTU是什么？
答案 0 :(得分：0)
是！
不幸的是，这就是目前Android的API的构建方式......
您可以将通知特性发送到Android设备作为解决方法。但为什么你需要从外围方面进行MTU协商？从Android方面做这件事应该是首选方式。