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. 報錯日志

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 重新 抓了一份 日志， 分析如下。

// 當車機主動斷開 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 --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__);
+ }