【android bluetooth 案例分析 03】【PTS 测试】【PBAP/PCE/SSM/BV-02-C】

1. 测试介绍

PBAP/PCE/SSM/BV-02-C $PCE Closes a PBAP Session$

1. Test Purpose

Verify that the PCE can terminate a PBAP session.

2. Initial Condition

IUT: The IUT is engaged in a PBAP session with the Lower Tester.
Lower Tester: The Lower Tester is engaged in a PBAP session with the PCE.

3. Test Procedure

The IUT attempts to disconnect the PBAP session.

4. Expected Outcome

Pass verdict

The IUT issues an OBEX DISCONNECT to the Lower Tester.

2. 测试过程中遇到的问题：

1. 报错日志

shell 复制代码

Test case : PBAP/PCE/SSM/BV-02-C started
- version=0x0102  rfcommPsm=0x02  l2capPsm=0x1005  supportRepositories=0x0f  supportedFeatures=0x000003ff 
- Final supported Feature 201
- Obex connection complete.
- Failed disconnection
- Received HCI disconnection event. Handle = 0x0063
	 -Final Verdict: FAIL
PBAP/PCE/SSM/BV-02-C finished

当车机发起断开 pbap 时，收到了 acl 断开。导致本次测试失败。

2. 日志分析

1. PTS 侧日志分析

PTS 侧的日志：

$537$ 车机发起了 pbap 断开， $538$ PTS 也做了回复。这块逻辑是符合测试的。
但从 log 中看到车机主动发起了 acl 断开 $645$

2. 车机侧日志分析

我们看一下车机侧的日志：

车机侧主动发起了断开。

3. 结论

PTS 报错是因为 Received HCI disconnection event。那车机不要主动断开 acl 即可。

方式一：

保持 acl 的方式有很多种，可以连多个协议，例如 hfp和 pbap 同时连，就可以保持车机不主动断开 acl.
- 尝试用这种方式，虽然车机没有主动发起 acl断连，但是依然有问题。

方式二：

找到车机主动断开acl 的地方，将其临时屏蔽掉即可。

3. 分析解决

加log 重新抓了一份日志，分析如下。

c 复制代码

// 当车机主动断开 pbap 时， 在 l2cu_release_ccb 中触发了 检查acl 定时器。
04-25 01:41:15.609809  5944  6005 I bt_l2cap: packages/modules/Bluetooth/system/main/bte_logmsg.cc:201 LogMsg: l2cu_release_ccb: cid 0x0041  in_use: 1
04-25 01:41:15.609837  5944  6005 I bt_btm  : packages/modules/Bluetooth/system/main/bte_logmsg.cc:198 LogMsg: BTM_SecClrServiceByPsm psm:0x0 num_freed:0
04-25 01:41:15.610222  5944  6005 I bt_l2cap: packages/modules/Bluetooth/system/main/bte_logmsg.cc:201 LogMsg: l2cu_dequeue_ccb  CID: 0x0041
04-25 01:41:15.610270  5944  6005 I bt_l2cap: packages/modules/Bluetooth/system/main/bte_logmsg.cc:201 LogMsg: l2cu_no_dynamic_ccbs() with_active_local_clients=1
04-25 01:41:15.610290  5944  6005 I l2c_utils: packages/modules/Bluetooth/system/stack/l2cap/l2c_utils.cc:2685 l2cu_no_dynamic_ccbs: trace_l2c_lcb_timer_timeout [l2cu_no_dynamic_ccbs:2685]

// 定时器时间为 4s
04-25 01:41:15.610428  5944  6005 I l2c_utils: packages/modules/Bluetooth/system/stack/l2cap/l2c_utils.cc:2688 l2cu_no_dynamic_ccbs: Started link IDLE timeout_ms:4000



// 4s 时间到后，发送了 disconnect 命令
04-25 01:41:19.610110  5944  6005 I l2c_link: packages/modules/Bluetooth/system/stack/l2cap/l2c_link.cc:467 l2c_link_timeout: L2CAP - l2c_link_timeout() link state:LST_CONNECTED is_bonding:false
04-25 01:41:19.610157  5944  6005 W l2c_link: packages/modules/Bluetooth/system/stack/l2cap/l2c_link.cc:498 l2c_link_timeout: TODO: Remove this callback into bcm_sec_disconnect
04-25 01:41:19.610191  5944  6005 I bt_btm_sec: packages/modules/Bluetooth/system/stack/btm/btm_sec.cc:3871 btm_sec_disconnect: Disconnect ACL Link handle: 0x0002 reason: Remote Terminated Connection comment: stack::l2cap::l2c_link::l2c_link_timeout All channels closed

具体 l2cu_release_ccb 为何调用l2cu_no_dynamic_ccbs 以及 l2c_link_timeout 是干什么的，可以参考我之前写的【android bluetooth 协议分析 06】【l2cap详解 11】【l2cap连接超时处理逻辑介绍】

根据分析，我们最后采用将 4s 延时改为 40s 。这40s 足够pts 去处理了。

diff 复制代码

diff --git a/system/stack/l2cap/l2c_utils.cc b/system/stack/l2cap/l2c_utils.cc
index 39d2949b80..694544ff66 100755
--- a/system/stack/l2cap/l2c_utils.cc
+++ b/system/stack/l2cap/l2c_utils.cc
@@ -42,6 +42,7 @@
 #include "stack/include/l2cdefs.h"
 #include "stack/l2cap/l2c_int.h"
 #include "types/raw_address.h"
+#include "osi/include/properties.h"
 
 tL2C_CCB* l2cu_get_next_channel_in_rr(tL2C_LCB* p_lcb); // TODO Move
 
@@ -2681,6 +2682,13 @@ void l2cu_no_dynamic_ccbs(tL2C_LCB* p_lcb) {
     }
   }
 
+  if (osi_property_get_bool("xxxx.bluetooth.pts", false)) {
+    LOG_INFO("%s:PTS process.",__func__);
+    timeout_ms = 40000; // 40s
+ } else {
+    LOG_INFO("%s: normal process.",__func__);
+ }

【android bluetooth 案例分析 03】【PTS 测试 】【PBAP/PCE/SSM/BV-02-C】