uni-app uni.onBluetoothAdapterStateChange回调异常
uni-app uni.onBluetoothAdapterStateChange回调异常
| 信息类别 | 详情 |
|---|---|
| 产品分类 | uniapp/App |
| PC开发环境操作系统 | Mac |
| PC开发环境操作系统版本号 | OS X EI Capitan |
| HBuilderX类型 | Alpha |
| HBuilderX版本号 | 3.0.7 |
| 手机系统 | Android |
| 手机系统版本号 | Android 9.0 |
| 手机厂商 | 华为 |
| 手机机型 | COR-AL00 |
| 页面类型 | vue |
| 打包方式 | 云端 |
| 项目创建方式 | HBuilderX |
操作步骤：
- 手机开启蓝牙功能
- 开启蓝牙扫描（uni.startBluetoothDevicesDiscovery）
- 手机关闭蓝牙功能，收到onBluetoothAdapterStateChange回调: {“discovering”:true,“available”:false}
- 关闭蓝牙扫描（uni.stopBluetoothDevicesDiscovery），返回成功
收到onBluetoothAdapterStateChange回调: {“discovering”:false,“available”:true}
预期结果：
上述第4步收到的回调应该是 {“discovering”:false,“available”:false} ，或者其它合理的处理。
实际结果：
上述第4步收到的回调应该是 {“discovering”:false,“available”:true}
bug描述：
uni.onBluetoothAdapterStateChange回调异常
重现步骤如下：
- 手机开启蓝牙功能
- 开启蓝牙扫描（uni.startBluetoothDevicesDiscovery）
- 手机关闭蓝牙功能，收到onBluetoothAdapterStateChange回调: {“discovering”:true,“available”:false}
- 关闭蓝牙扫描（uni.stopBluetoothDevicesDiscovery），返回成功
收到onBluetoothAdapterStateChange回调: {“discovering”:false,“available”:true}
BUG: 上述第4步收到的回调中 available 不应该是 true.
相关1: 同样的操作流程，小程序在第3步收到的回调是 {“discovering”:false,“available”:false} ，在第4步不会收到回调信息。
相关2: 如果手机关闭蓝牙功能后，程序不调用 uni.stopBluetoothDevicesDiscovery 来关闭蓝牙扫描，会有问题吗？
相关3: 第3步的回调哪个更合理，{“discovering”:true,“available”:false} 还是 {“discovering”:false,“available”:false} ？
相关4: 第4步哪种处理更合理，回调 {“discovering”:false,“available”:false} 还是 不回调？
谢谢！
更多关于uni-app uni.onBluetoothAdapterStateChange回调异常的实战教程也可以访问 https://www.itying.com/category-93-b0.html
如果手机关闭蓝牙功能后，不须要主动关闭蓝牙扫描的话，我这边暂时可以绕过去。
更多关于uni-app uni.onBluetoothAdapterStateChange回调异常的实战教程也可以访问 https://www.itying.com/category-93-b0.html
在收到onBluetoothAdapterStateChange回调: {“discovering”:false,“available”:true} 之后，开启蓝牙扫描（因为程序认为蓝牙已经开启），返回错误：10015.
如果收到 10015 就可以认为蓝牙已关闭，那我这边也可以处理一下。
在收到错误10015后再次调用 uni.getBluetoothAdapterState 获取状态，与回调返回的值一致： {“discovering”:false,“available”:true}
请提供简单、可稳定复现、能直接运行的完整示例（上传附件），方便我们快速排查问题哦。
【bug优先处理规则】https://ask.dcloud.net.cn/article/38139
