bdbb2527e6
All checks were successful
Sync To /home/ubuntu/gfps / sync (push) Successful in 2s
Change-Id: I71e676b997159a141ca07d16f82a73b45f4b2410
70 lines
4.7 KiB
Markdown
70 lines
4.7 KiB
Markdown
# Pairing failed！\[Pair time-out\]
|
||
|
||
<a href="/download/attachments/1066107675/140522%20Pairing%20Failed%20Pair%20timeout.zip?version=1&modificationDate=1772940907323&api=v2" data-linked-resource-container-id="1066107675" data-linked-resource-container-version="3" data-linked-resource-content-type="application/zip" data-linked-resource-default-alias="140522 Pairing Failed Pair timeout.zip" data-linked-resource-id="1066107679" data-linked-resource-type="attachment" data-linked-resource-version="1" data-nice-type="Zip Archive">140522 Pairing Failed Pair timeout.zip</a>
|
||
|
||
|
||
|
||
\
|
||
|
||
原因是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
|
||
|
||
\
|
||
|
||
**<span style="color: rgb(255,0,0);">问：</span>**
|
||
|
||
设备端断开L2cap的原因是设备端没有收到手机端主动连A2dp/hfp ，这好像是符合蓝牙spec的， 设备是支援le audio的TWS耳机，手机也支援le audio, 是不是手机本身就不会连A2dp/hfp, 而是会通过le audio交互音频数据
|
||
|
||
\
|
||
|
||
**<span style="color: rgb(255,0,0);">答：</span>**
|
||
|
||
\*\*在支持 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\`。
|
||
|
||
\
|
||
|
||
\
|
||
|
||
\
|
||
|
||
\
|
||
|
||
\
|