多次循环调用【BLEPeripheralServer.startAdvertising()、BLEPeripheralServer.stopAdvertising()】后，最后再调用BLEPeripheralServer.stopAdvertising()偶现广播不能停止，其它设备还是能接收到广播。

手机：红米K40 打开小程序的调试窗口会有日志打印，点击开始扫描，小程序会扫描设备，开始扫描后将手机锁屏5～8分钟，再次打开小程序发现搜不到设备了。 扫描时通过services: ['FFE0']过滤蓝牙设备，测试发现如果不设置过滤则锁屏几分钟后也能搜到蓝牙设备，只有设置了过滤条件才会搜不到蓝牙设备。我这儿可以确定的是蓝牙设备是一直在发广播包的。

自定义tabbar与picker代码都是使用的官方示例代码。安卓手机和开发者工具显示正常，苹果手机显示异常，已上传代码片段，异常截图如下：[图片]

canvas使用的是最新Canvas 2D 接口。 createConicGradient方法在开发者工具中可以正常调用，在真机预览时无法绘制并有异常提示 t.createConicGradient is not a function。 已补充代码片段，开发者工具截图与真机预览异常截图如下：[图片][图片]

API为：BLEPeripheralServer.startAdvertising(Object Object) 安卓原生蓝牙广播可以配置广播时长，API为：advertiseSettings = new AdvertiseSettings.Builder().setTimeout(1500).build();  如果可以的话希望小程序可以增加广播时长字段，这样小程序功能更完善，某些场景中开发起来也更方便。

应用(智灯plus)发布后，部分用户偶现小程序会一直发送蓝牙广播包，即使杀死小程序或把小程序删掉还是会发送广播包。只有把蓝牙关闭后广播包才会停止。 出现这个问题的手机有： 华为 nova 8SE [图片] Vivo NEX S [图片] 但只两个手机也只是偶现这个问题。 安卓在配置蓝牙广播参数时是可以配置广播时长的，微信官方可以在小程序的参数配置中加上这个参数吗，这样的话就算微信调用原生蓝牙广播出现持续广播的bug，只要原生那里配置了广播时长影响也不大。 [图片] 现在很多智能家居可以用蓝牙广播的方式去控制设备，好处是无需蓝牙连接，方便快捷。如果有这个bug存在的话就会出现控制紊乱，影响很大，希望官方可以多关注一下。

[图片] iOS没这个问题，安卓app也没这问题。只有安卓的微信小程序会这样，且提示“already connected”错误。实际上这问题我去年就提过了，链接：https://developers.weixin.qq.com/community/develop/doc/000c0cea6e44a84ae14bf8ad05b000。 当时工作人员说下个版本会处理，现在半年过去了，也没解决这问题。 现在手机连手环的用户越来越多了，希望微信官方可以重视这个问题，这个问题对很多智能家居类的小程序影响很大。

假如手机连上耳机。用其它手机app可以正常发包，但是微信小程序发包就会失败(bleServer.startAdvertising),希望这部分功能使用现在能和app保持一致，即蓝牙是否连接与能否发包无关。错误日志如下图[图片]

主要是考虑到安全性，准备把一些涉及到加密的代码写在云函数中，不知道第三方是不是有办法能调用我的云函数。

手机：小米6 Android9 有两个问题需要反馈。 以代码片段举例，先打开手机蓝牙，然后匀速左右滑动进度条大概持续10S。然后拿另一个手机打开nrf connect这个广播包抓包工具，用BBAA过滤广播数据，搜索广播包。 问题一：每次我发包都是在停止上一次广播成功的回调中进行，结果控制台还是有打印提示发包失败，已经开始发包了(截图1)。 问题二：当你停止滑动后，增加过滤条件，重新搜索广播包，在nrf connect中应该只有一条广播包，结果测试发现有时候居然同时有4条广播数据一直被接收(截图二)，当你退出小程序后也会有三条广播包一直在发送，只有重启手机才会停止发送。 综上所述，问题二是很严重的问题，因为在某些产品中，每一个广播包都相当于一个命令，当有问题二存在时，产品就会一直执行这些不同的命令，直到用户重启手机。[图片][图片]