测试机与辅助机配对蓝牙成功后,关闭辅助机蓝牙开关,测试机给辅助机通过蓝牙分享一张图片,提示"蓝牙共享,未发送文件"间隔时间过长,25秒左右
测试机与辅助机配对蓝牙成功后,关闭辅助机蓝牙开关,测试机给辅助机通过蓝牙分享一张图片,提示"蓝牙共享,未发送文件"间隔时间应当5秒左右
测试步骤:
1.测试机与辅助机配对蓝牙成功
2.进入设置->蓝牙,选择连接蓝牙偏好设置,选择蓝牙,关闭蓝牙开关
3.测试机给辅助机通过蓝牙分享一张图片
4.提示"蓝牙共享,未发送文件"间隔时间过长
解决方案
root cause:
1.page timeout=12.8s
2.发起OPP后有两次create connection过程,一次是SDP建立的,另一次是RFCOMM连接建立的
所以两次都page timeout的话,总的时间就是25.6s
solution:
修改了page timeout的时间,改为了7.68s,所以等待时间缩短到了15s
响应时间长主要是有两个原因:
-
在测试机发出OPP传输请求的时候,首先需要建立ACL link,也就是要去page辅助机,由于辅助机关闭了蓝牙,所以page的过程就会等待timeout才会结束。
目前page timeout的设定是12.8s,也就是page了12.8后才会停止并且上报page timeout的status。
这个12.8s由两个方面来控制,一个是BT stack,stack设定的默认值是5.12s,另一个是controller,controller会根据stack设定的值对page timeout时间进行调整,规则是:
当stack设定值>=7.68s时,会采用stack设定的值;当stack设定值<7.68s时,会补偿7.68s,也就是设定为5.12s+7.68s=12.8s,(这个是在bt firmware里面的,firmware是binary release,看不到代码的。)
这么做的理由是,通常我们不是单纯做page,还会有multi link、coex的分时等,所需要对page时间做补偿,以保证page performance,比如在复杂环境中,保证page的时间,才能确保收包可靠性。 -
另一个原因是,由于之前已经配对过,所以在发起连接的时候,第一次page失败后,stack会再下发一次连接请求,这种机制是为了确保复杂环境中仍能会连上设备。
基于上述两个原因,所以目前发起OPP后,如果对端不在可连接状态,则会等待12.8+12.8=25.6s再上报无法传输的广播。如果要优化的话,可以考虑把page timeout改为controller不会调整的最大可设定值,也就是7.68s,而原因2的地方不建议改动,因为修改了重连机制可能导致正常的连接成功率下降。
page timeout的修改方式:
system/bt/bta/dm/bta_dm_cfg.cc
41 /* page timeout in 625uS */
42 #ifndef BTA_DM_PAGE_TIMEOUT
43 #define BTA_DM_PAGE_TIMEOUT 8192 ==> 12300
44 #endif
8195X0.625uS=5.12s
12300X0.625uS=7.68s
这部分的机制是:
- 蓝牙文件传输用的是OPP协议,OPP协议是建立在RFCOMM的基础上的
- 正常OPP的流程是:上层发起OPP传输请求—>SDP search(搜索对端OPP服务)—>搜索成功后建立RFCOMM连接—>建立成功后开始传输文件
- 在SDP search过程中,会先去建立ACL link(也就是底层的物理传输链路),然后对端将SDP的数据传给本机;但在本CR的测试步骤中,由于此时对端蓝牙关闭了,所以建立ACL link的过程失败了(page timeout),stack上报sdp search fail
- 收到sdp search fail的消息后,仍会继续进行下一步,也就是建立RFCOMM连接,这步同样是建立在ACL link上的,由于上一步ACL link没建立起来,所以这步会再次尝试建立ACL link,就会再次经历一个page time;而如果是正常流程,在SDP search的过程中就已经建立起ACL link了,所以在RFCOMM连接的时候就不会重复发起ACL link的连接请求。
目前没有其他优化的方式了,因为page timeout不能改的太小,否则会影响page性能;OPP传输的流程也不建议改动,因为对于不支持L2CAP的OBEX,只能通过RFCOMM传输,如果把RFCOMM连接过程拿掉,可能影响OPP连接的建立