[Jgckm]

Summary

戴灵 T3 的认证顺序与维护版的假设相反：设备收到开场 00 + 16 字节随机数后，先回自己的 01
包；直到模块发出 02 70 61 73 73，它才下发参与哈希的 00 挑战。维护版要求第一阶段必须是
00，因此在第二步就触发 HandshakeRejected，三次重试后进入 60s 退避，私有电量、三态和
游戏模式都不再发布。

本 PR 按厂商 App 的 HCI 抓包，把状态机改成 GREETING(01) → CHALLENGE(00) → CONFIRM(02)，
并让 reset() 回到问候阶段，否则每次重连都会复现同样的拒绝。

Scope and impact

• integration：DailingT3ProtocolSession 的认证阶段机；DailingT3AdapterTest 的顺序与分片用例。

• docs/dailing-t3-protocol.md：认证表按抓包更正，并注明第 2 步不是拒绝。

• CHANGELOG.md：在「戴灵 T3（维护验证）」下记录本次认证顺序修正。

• 不改通用会话、卡片扩展、传输层、控制 App 目录或其他型号。

• This change follows the project scope; detailed configuration remains in vendor control apps

Evidence

以下是厂商 App com.dailing.audio 驱动同一台 T3（固件 1.6.0，2026-11-14）时的 HCI 抓包，
RFCOMM DLCI 2：

12:44:25.948  TX  00 73 51 FF 4A EC 29 CD BA AB F2 FB E3 46 7C C2
12:44:26.004  RX  01 86 C2 33 F8 E3 38 43 83 AB C2 01 9E 53 3B FF 4B
12:44:26.009  TX  02 70 61 73 73
12:44:26.070  RX  00 62 20 F2 40 94 F6 69 71 1D E3 C3 B1 03 B4 F4 61
12:44:26.075  TX  01 01 B1 B5 F1 FA DD 90 38 F6 78 E4 B9 AE DD 57 59
12:44:26.083  RX  02 70 61 73 73

维护版修复前，同一台设备上的实机边界：

wrote    00 6B 76 D8 53 36 01 A4 ...
received 01 27 B2 D6 92 BF 72 E4 ...
transport rfcomm-1-insecure failed: IOException:protocol rejected active adapter

Validation

• testDebugUnitTest
• :system-module:lintRelease
• :system-module:assembleRelease
• Hardware validation, when behavior changes on a physical headset
• For a maintained device PR: the final maintenance version has received device revalidation
• Logs, screenshots and Bluetooth addresses are redacted
• Documentation and compatibility status is updated
• If controller apps changed: catalog, Adapter declarations, scope.list, tests and
  docs/control-apps.md are synchronized

实机范围：Xiaomi 15 Pro / OS4.0.0.19.XOBCNXM / Android 17，debug 构建 30302（未签名）。

• 握手：收到 01 … / 00 … / 02 70 61 73 73 后紧接设备信息帧，handshake=true。
• 电量：私有协议左右耳（左 80%；右耳在盒，显示为未知；盒电量未知）。
• 三态：在应用内卡片切 ANC，写入 C0 08 … FF 0A 0D 01 60 00 …，回读 C0 07 … 20，状态为
  ANC；在原生卡片切通透，写入 FF 0A 0D 02 40 00 …（与厂商抓包逐字节一致），状态为
  TRANSPARENCY。
• 游戏模式：在原生卡片打开开关，写入 C0 C0 … 02 05 02，回读 C0 C1 … 20，enabled=true；
  关闭后写入 02 05 01，enabled=false。
• 原生卡片：融合设备中心显示 DaiLing T3 80% | 降噪；卡片扩展复用原生三态布局，保留标题与
  「更多设置」。
• 厂商 App 退避：registered com.dailing.audio 之后，状态退化为 handshake=false，只剩标准
  电量；unregistered … (process death) 之后，会话重新建立并恢复私有特性。
• 「更多设置」：日志为 opened headset settings bridge=stable-controller，跳转目标为 HyperEars。

流程状态

• 本 PR 基于 Maintain DaiLing T3 core RCSP integration #131 的维护分支 codex/pr129-dailing-maintenance；Maintain DaiLing T3 core RCSP integration #131 保持 Draft，Add DaiLing T3 (JieLi RCSP) adapter with card extension #129 保持开放。
  待签名维护包复核通过后，再依次合入 Maintain DaiLing T3 core RCSP integration #131 并关闭 Add DaiLing T3 (JieLi RCSP) adapter with card extension #129。
• .github/workflows/ci.yml 的 pull_request 只监听 main，本 PR 不会触发 CI；上面三项 Gradle
  校验由本地同一组命令执行。
• 未签名的 debug 构建不能替代签名维护包的实机复核，因此最后一项保持未勾选。

Risks and rollback

• 认证顺序只按单一固件（1.6.0）实测。其他固件若仍走旧顺序，会在 GREETING 阶段被拒绝，表现与
  当前维护版一致，即休眠而非崩溃。
• 只改会话内部状态机，不涉及传输、退避、卡片绑定或共享会话代码，回滚时撤销本提交即可。
• ANC 写入仍使用 60 00 参数，而厂商 App 使用 7F FF 40 00 7F FF 7F FF；设备接受并正确回读，
  但听感差异建议在签名包复核时确认。

[Jgckm]

最终验证状态（Xiaomi 15 Pro / OS4.0.0.19.XOBCNXM / Android 17，debug 构建 30302，未签名）：

• 握手：收到 01 … / 00 … / 02 70 61 73 73 后紧接设备信息帧，handshake=true。
• 私有电量：左 80%；右耳在盒，显示为未知；盒电量未知。
• 三态：ANC 写入 C0 08 … FF 0A 0D 01 60 00 …，回读 C0 07 … 20，状态为 ANC；通透写入
  FF 0A 0D 02 40 00 …（与厂商抓包逐字节一致），状态为 TRANSPARENCY；关闭写入
  FF 0A 0D 00 …，状态为 OFF。
• 游戏模式：写入 C0 C0 … 02 05 02，回读后 enabled=true；写入 … 02 05 01，enabled=false。
• 原生卡片：融合设备中心显示 DaiLing T3 80% | 降噪；卡片扩展复用原生三态布局，保留标题与
  「更多设置」。
• 厂商 App 退避：registered com.dailing.audio 之后，状态退化为 handshake=false，只剩标准
  电量；unregistered … (process death) 之后，会话重新建立并恢复私有特性。
• 「更多设置」：日志为 opened headset settings bridge=stable-controller，跳转目标为 HyperEars。

未覆盖：签名维护包复核（需由维护流程重出构建）、长期稳定性、其他固件。