bdbb2527e6
Change-Id: I71e676b997159a141ca07d16f82a73b45f4b2410
4.7 KiB
Pairing failed！[Pair time-out]
140522 Pairing Failed Pair timeout.zip
\
原因是BR ACL link 建立之后，4s没连legacy profile， 设备端主动把BR ACL link 断掉了，导致GFPS 流程异常
Line 81655: 0008329 03-03#14:05:14.028 249 0047231.527 [APP] !**connected: b2s, bd_addr AC::3E::B1::09::07::C6, profs 0x00000000
\
问：
设备端断开L2cap的原因是设备端没有收到手机端主动连A2dp/hfp ，这好像是符合蓝牙spec的， 设备是支援le audio的TWS耳机，手机也支援le audio, 是不是手机本身就不会连A2dp/hfp, 而是会通过le audio交互音频数据
\
答：
**在支持 LE Audio 的双模（Dual-Mode）TWS 耳机测试中，Android 手机（特别是支持 LE Audio 的较新系统）的配对和连接行为确实与纯经典蓝牙耳机有很大不同。** 手机在连接时会优先进行 LE Audio 的服务发现和配置，从而“冷落”或延迟建立经典蓝牙的 A2DP/HFP 业务。
这不仅没有推翻之前的分析，反而**完美地解释了为什么会发生 L2CAP 超时。** 之前的分析依然绝对可靠，我们可以结合 LE Audio 的特性来彻底还原这个 Google 测项失败的完整逻辑。
### 1. 为什么说分析依然可靠？（结合日志的铁证）
在左耳（COM4）主动断开经典蓝牙连接（14:05:18.140）的**同一毫秒**，我们看看耳机在 BLE 链路上正在忙什么：
```text
0004586 03-03#14:05:18.140 005 [PROTOCOL] !**ascs_attr_read_cb: attrib_index 8, offset 0
0004587 03-03#14:05:18.140 006 [PROTOCOL] !**ase_gen_char_data: ase_id 2, direction: 1, ase_state 0, len 2
0004588 03-03#14:05:18.140 007 [BTIFMSG]↙BTIF_MSG_GATT_ATTR_READ_CFM...
...
0004594 03-03#14:05:18.140 013 [PATCH] l2c_handle_timeout: timer_id 0x84, timer_chann 0x0042
0004595 03-03#14:05:18.140 014 [HCI] !**hci_cmd_disconnect: handle 0x0002, cause 0x13
0004599 03-03#14:05:18.140 018 [MODULE_LOWERSTACK] ... --> send lmp opc:7 ... Name is LMP_detach
```
**解析：**
* `ascs_attr_read_cb`：**ASCS (Audio Stream Control Service)** 是 LE Audio 的核心服务。这证明手机此刻并没有闲着，它正在疯狂地通过 BLE 读取耳机的 LE Audio 属性（GATT Discovery）。
* 手机在 `14:05:14` 的时候，其实已经顺手把经典蓝牙的底层 ACL 链路（handle `0x0002`）建好了（为了双模兼容性）。
* 但是，因为手机正忙着在 BLE 上配置 LE Audio，它**延迟了**在经典蓝牙链路上发起 SDP / A2DP / HFP。
* 耳机端（底层协议栈）有个死板的定时器（`timer_id 0x84`）：如果经典蓝牙 ACL 建连后大约 **4 秒内**没有收到 Profile 级的 L2CAP 交互（`timer_chann 0x0042`），耳机就认为经典链路是“死链接”，从而**主动将其断开**。
**结论：** 手机觉得“我正在忙着配 LE Audio，经典蓝牙你先等着”，但耳机觉得“经典蓝牙连上了4秒你还不理我，我把你挂了”。**耳机主动挂断经典蓝牙，导致 Android 系统的蓝牙状态机认为整个双模配对流程出现异常，从而在 3.8 秒后（14:05:22）把 BLE 链路也彻底断了，报出 Pairing Failed。**
\
您的耳机固件目前的逻辑对于纯经典蓝牙是合理的（防呆机制，防止占着信道不发数据），但**对于 LE Audio 双模流程来说是致命的 bug**。
**修复建议：**
1. **修改 L2CAP Idle Timeout 机制**：
在检测到当前正处于 Google Fast Pair 流程中，或者当前 BLE 链路正在进行 LE Audio (ASCS/PACS) GATT 发现时，**必须显著延长或直接禁用经典蓝牙侧的 L2CAP 空闲断开定时器（将 4 秒至少延长至 15-30 秒，或者等待 BLE 侧彻底配置完毕）**。
2. **状态机关联**：
让经典蓝牙的连接状态机能够“感知”到 BLE 侧的繁忙状态。只要 BLE 侧的 GFPS/LE Audio 协商还在进行，就允许经典蓝牙保留一条没有 Profile 数据的“空” ACL 链路，不要主动发送 `LMP_detach`。
\
\
\
\
\