gfps: 添加认证测试和FAQ 20260505

Change-Id: I71e676b997159a141ca07d16f82a73b45f4b2410

Pairing+failed！[Pair+time-out].md

@@ -0,0 +1,69 @@
+# Pairing failed！\[Pair time-out\]
+
+<a href="/download/attachments/1066107675/140522%20Pairing%20Failed%20Pair%20timeout.zip?version=1&amp;modificationDate=1772940907323&amp;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>
+
+![](images/Pairing+failed！%5BPair+time-out%5D_d717feaa.jpg)
+
+\
+
+原因是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\`。
+
+\
+
+\
+
+\
+
+\
+
+\