Android Bluetooth page timeout问题

Android蓝牙连接超时时间 蓝牙配对时间过长

https://blog.51cto.com/u_13019/7750311

 

测试机与辅助机配对蓝牙成功后，关闭辅助机蓝牙开关，测试机给辅助机通过蓝牙分享一张图片，提示"蓝牙共享，未发送文件"间隔时间应当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

 

响应时间长主要是有两个原因：

1. 在测试机发出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的时间，才能确保收包可靠性。
2. 另一个原因是，由于之前已经配对过，所以在发起连接的时候，第一次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

  /* page timeout in 625uS */
  #ifndef BTA_DM_PAGE_TIMEOUT
  #define BTA_DM_PAGE_TIMEOUT 8192  ==> 12300
  #endif

8195X0.625uS=5.12s
12300X0.625uS=7.68s

 

这部分的机制是：

1. 蓝牙文件传输用的是OPP协议，OPP协议是建立在RFCOMM的基础上的
2. 正常OPP的流程是：上层发起OPP传输请求—>SDP search（搜索对端OPP服务）—>搜索成功后建立RFCOMM连接—>建立成功后开始传输文件
3. 在SDP search过程中，会先去建立ACL link（也就是底层的物理传输链路），然后对端将SDP的数据传给本机；但在本CR的测试步骤中，由于此时对端蓝牙关闭了，所以建立ACL link的过程失败了（page timeout），stack上报sdp search fail
4. 收到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连接的建立