问题背景：

一台公版GK6320板子,一台GK6780板子，蓝牙wifi均已打开，sink端打开文件互传开关；source端进入文件管理器，选择一个图片文件，选中分享按钮，进行扫描，等待扫描出设备进行分享，结果一直扫描不到设备。

 

定位过程&根因分析：

A00220/OneConnectShareApp: ShareManager: startScan in

从日志分析来看，source是开启了扫描的。从startScan in到[BleAdapter] StartAdvertising均有正常的日志输出，但Bluetooth: [BleAdapter] StartScan及其后的日志未输出，分析可能是未扫描到sink端发出的广播导致。

那么首先就要弄清楚，sink发出文件互传的广播，报文格式是怎样的，通过查看代码与技术规范，发现sink端在打开文件互传的按钮之后，发出的广播应是uuid为0xfe35的广播。

 

那么需要查看sink端的snoop确定是否发出了uuid为0xfe35的广播。

日志显示sink端只发送了uuid为默认的0xfdee的这一种广播，现在确定sink端广播发错了，扫描端当然扫不到设备了。现在要去查看代码流程中，设置广播数据的位置，为什么uuid没有设置为0xfe35.

 

通过查看代码流程与添加日志打印，确定了软总线在打开sink端文件互传按钮后设置广播数据包的位置。

通过添加日志也能确定，软总线在向蓝牙设置广播数据时，uuid设置的无误。

 

那么继续往下追，发现在一直走到了蓝牙服务层之后，最终调用到了一个为实现的接口，走了一个断头路。

问题出现在蓝牙服务层，接口调用到这里后，功能没有实现了，那么广播肯定就发布出去了。

 

那么0xfdee的广播又是如何成功发送出去的呢，在流程中一定有个不同的分支。于是继续查看代码。

 

通过继续查看日志与代码，发现在这个接口中，我们的设置0xfe35广播数据在这里走向了UpdateAdvertiser分支。而0xfdee则走向了下面的SchedulerStartBroadcast中。那么现在就比较明朗了，UpdateAdvertiser接口往下去调用蓝牙服务层接口去更新广播数据这个功能，蓝牙并不支持，目前蓝牙只支持重新发广播。

 

最终结论：同时比对了rk3568文件互传成功的snoop日志，sink端中发出的广播就只有0xfe35的广播，那么也是走的SchedulerStartBroadcast分支，而我们gk6320开发板，一开机就有其他服务调用了蓝牙发送了x0fdee的广播，后续我们文件互传功能再发广播时，在这个接口中判断是否已有广播发送之后，就走到了更新广播数据的分支了，由于蓝牙服务层不支持在发出广播后再更新广播数据，所以文件互传的0xfe35的广播没能成功发送。

 

解决方案：

在StartAdvertiser接口中，判断advertiser->isAdvertising的分支中，注释掉GetNeedUpdateAdvertiser逻辑，让蓝牙重新发送新的0xfe35的广播而不去更新已发的蓝牙广播。

编译镜像后测试，通过sink端的snoop日志，已经再发0xfdee与0xfe35两种广播，但是source还是未搜索到。

使用手机调试助手，也只能搜索到0xfdee的广播，并没有搜索到0xfe35的广播，说明广播在蓝牙模组上还是没有成功发出来。

怀疑此模组不支持多路广播，所以尝试先暂停之前发送的广播然后再发新的广播。

再次测试发现终于成功发出了0xfe35的广播。