问题背景：

文件互传功能从统一互联移植到Gk6780dev分支后，传输功能基本ok，但出现开机后第一次分享图片成功，第二次传输在输入完PIN码后必现传输失败，后面继续图片分享均失败，关机重启可恢复，但仅限于第一次传输成功，后续传输必现失败。

 

定位过程&根因分析：

从应用分析来看，显示第二次传输在连接后，应用在等待对端的消息等待15s，未等到随后应用走了传输失败流程。

 

随后底层分析未收到消息的原因。看应用代码逻辑是应用要收到底层的连接状态，收到的状态为1才会继续走下一步，但目前应用什么消息都未收到。初步怀疑是第一次传输成功后的解绑流程有问题，相关信息或缓存没有清空，第二次连接还认为处于绑定状态。

 

随后我们尝试在第二次传输前，再次强制调用接口进行解绑。

 

验证结果还是失败，但看了DHDM的解绑流程，解绑成功未发生相关报错。

 

需要分析Disconnect接口调用逻辑是否有问题。

我们在第一次传输后，手动杀死DHDM进程或者手动杀死应用进程，第二次也能成功传输文件，于是尝试了规避方案，就是在每次文件传输完成后应用将进程杀掉，后续传输图片在重启应用，但出现以下问题：

第一次传输：成功。

第二次：点击分享无反应。

第三次：再次点击分享，发现设备。输入完pin码后，source端界面消失，sink端无反应但实际图片传输成功。

第四次：点击分享无反应。

第五次：再次点击分享，发现设备。输入完pin码后，source端界面消失，sink端无反应，但实际图片传输成功。

问题原因为应用进程在第一次传输完成后被杀死，随后第二次点击传输应用才启动，所以点击无反应，再次点击才能成功进入传输流程。要解决此问题就得设置应用为保活模式，但根据策略文件传输应用不能设置为保活。

所以继续从Disconnect接口分析定位。

Disconnect接口实际上也是调用的DM的UnBindDevice接口。但是UnBindDevice最终是调用成功的，问题肯定出现在此接口中。

 

比对第一次传输成功与第二次传输失败的日志，发现第二次传输没有执行OnSoftbusDeviceOnline这个回调，后续连接流程没有继续往下走了。继续比对了rk3568的日志，发现解绑过程中，GK6780解绑过程OnSoftbusDeviceOffline没有执行，所以第二次传输的时候可能会默认设备在线然后不会触发OnSoftbusDeviceOnline这个在线回调。

 

在代码中查找OnSoftbusDeviceOnline与OnSoftbusDeviceOnline。

这两个回调是监听软总线在线离线状态的，那么此问题就比较清晰了，应该就是设备在第一次传输后解绑没有回调到OnSoftbusDeviceOffline事件了，去解绑流程中查找这个问题原因就可以了。

 

继续查看日志与源码，发现走到了APP级绑定的最后一个设备解绑分支。发现在这个分支中解绑后没有调用softbusConnector_->HandleDeviceOffline(remoteUdid);通知离线。

 

解决方案：

在APP级绑定的最后一个设备解绑分支中，在删除认证后添加通知设备离线。

代码修改如下：

 

编译验证，传输文件四次，第二次及之后几次均能传输成功。