Quartz 4

🔍 搜索

45 · Door.STATE 不可用致 autoConnect 全灭 + hci1 snoop 崩溃 — MIICOSBUG-4733

6 min read

45 · Door.STATE 不可用致 autoConnect 全灭 + hci1 snoop 崩溃 — MIICOSBUG-4733

源码基线:MiCarSettings rls-xcd-x-ee-2608-2609 HEAD a8a6efe6；MiCarBluetoothService rls-xcd-x-ee-2609；TSP 日志 MIICOSBUG-4733/tsp-log。交叉引用:66-bond状态与自动回连、31-连接与自动连接策略、40-日志取证速查。 本案价值:“Saved/低亮”先判真实未连接还是 UI 假态；autoConnect 触发了 ≠ 建链了；抓 bugreport 不能让日志系统杀掉被诊断栈。

0. 结论先行(TL;DR)

  • JIRA 现象「首次连接后名称低亮」经视频+TSP 复核，不是 Settings 高亮失效，而是 Galaxy S26 Ultra 真实处于 Saved/未连接。
  • 主根因:Door.STATE(0x66403101=1715482881) 在 E4U2 车上返回 UNAVAILABLE 且时间戳冻结，CarServiceAutoConnectProxy 的 isDoorClosed() 门控 fail-closed，autoConnect 只入队、不发 HFP connect。全部成功连接均来自用户手动点击。
  • 另案 P0:抓 bugreport 时第二蓝牙栈 com.android.bluetooth1 在 snoop_logger.cc:1481 因 /data/misc/bluetooth/logs/hci1/btsnooz_hci.log EACCES 被 LOG_ALWAYS_FATAL 杀死，adapter 1 全部连接中断；13/26 车共 39 次同型。
  • MiCarSettings 无责：首连正确蓝色、Saved 与 isConn=false 一致、手动 Saved→Connecting→Connected 全链正确。

1. 快速判别：Saved/低亮到底是 UI 假态还是真实未连接

证据指向真实未连接指向 UI 假态
点击已配对条目走 connectDevice() → Connecting→Connected走断开确认/详情页
refresh ui 日志isConn=false 且 summary=SavedisConn=true 但 summary/颜色未变蓝
栈侧 profile/ACL无 CONNECTED/无建链已 CONNECTED，只是 UI 未刷新

本案决定性行为：BluetoothBondedDevicesPrefController.handlePreferClick():187-198 直接读实时 cachedDevice.isConnected()。视频与日志均走 connect 分支，不走断开确认，因此不是「已连接但没高亮」。

2. autoConnect 全链路：触发 ≠ 建链

BluetoothDeviceManager.java:609-643
  autoConnectWithTimeout(每设备 8s)
    -> connect(device)                (:562)
      -> mMiCarDevice.autoConnect(device)
        -> MiCarBluetoothDeviceManager.java:227-235
             startAutoConnect(device)
          -> CarServiceAutoConnectProxy.java:71-87
               isSeatOccupied()?  ─┐
               enqueue             ├─ AND 门控
               isDoorClosed()?    ─┘
               startAutoConnectIfReady(false)
            -> CarServiceAutoConnectProxy.java:253-263
                 HFP service.connect(device)

关键：外层日志 MiCarBluetoothDevice: autoConnect 只说明任务触发；只有最后 HFP service.connect 执行，栈侧才会出现 bt_btif_queue/ACL。本案 8 次 autoConnect 触发、0 次栈侧建链，说明阻塞点在中间件门控，而不是协议栈或手机拒绝。

3. Door.STATE 幻影门开的判据

日志指纹

CarServicesSignalHelper: Invalid Property:
MiCarPropertyValue{mPropertyId=0x66403101, mStatus=0x1, mValue=0}
  • 0x66403101 = 1715482881 = Door.STATE（MiCarSettings MiCarPropertyIds.java:167 注释可交叉验证）。
  • mStatus=0x1 = UNAVAILABLE；本案四次读取的 mTimestampNanos 完全相同，说明值冻结而非真门开。
  • 车辆以 66~67km/h 行驶，车门物理上不可能打开——UNAVAILABLE 是信号未提供造成的幻影门开。

时序指纹

  • autoConnect 后 3~80ms 读到 Invalid Property；
  • 随后没有任何 HFP/ACL 建链；
  • 外层 8s 后打印 Auto connect process has timed out connecting to <device>;
  • 手动点击绕开代理后 1~2s 立即连接成功。

满足这四条，优先查 CarServiceAutoConnectProxy 的门控信号，不要再查 Settings 高亮。

4. 平台另案：hci1 snoop 日志权限崩溃

触发链

com.mi.car.feedback START_DUMP
  -> dumpstate
    -> bt_gd_shim Stack::Dump(第一栈,成功)
    -> bt_gd_shim Stack::Dump(第二栈)
      -> SnoopLogger::DumpSnoozLogToFile
        -> open(/data/misc/bluetooth/logs/hci1/btsnooz_hci.log) = EACCES
          -> LOG_ALWAYS_FATAL
            -> SIGABRT com.android.bluetooth1
              -> BluetoothManagerService Recovery #1

本案第一栈同刻 dump 成功，第二栈崩在 hci1/ 子路径，构成天然 A/B 对照：btsnooz 文件/目录的 ownership 或 SELinux 对第二栈 uid(本例 1401002)不正确；同时 LOG_ALWAYS_FATAL 把日志失败放大成整栈死亡。

修复原则

  1. 日志失败永不杀栈：打开失败降级 LOG(ERROR) 并跳过 dump。
  2. 修第二栈日志路径权限：init/服务启动时创建 hci1/ 并 chown 到第二栈 uid，补 sepolicy；验收用 ls -lZ /data/misc/bluetooth/logs/。
  3. 连续抓 10 次 bugreport，com.android.bluetooth1 不得死亡、adapter 1 连接不得中断。

5. 取证命令（本案实跑版）

# 1) autoConnect 触发与 8s 超时
zgrep -E 'MiCarBluetoothDevice: autoConnect|Auto connect process has timed out' \
  FS/data/milog/logcat/logcat*.gz
 
# 2) Door.STATE UNAVAILABLE
zgrep -E 'CarServicesSignalHelper: Invalid Property.*0x66403101' \
  FS/data/milog/logcat/logcat*.gz
 
# 3) 是否真发 HFP/ACL（空结果=门控未放行）
zgrep -E '<mac尾4>|bt_btif_queue|acl_up|connectAllEnabledProfiles' \
  FS/data/milog/logcat/logcat*.gz
 
# 4) snoop 崩溃签名
zgrep -E 'DumpSnoozLogToFile: Unable to open snoop log|roid\.bluetooth1|Bluetooth is recovered' \
  FS/data/milog/logcat/logcat*.gz

6. 反陷阱清单

陷阱正解
看到低亮就查颜色/主题先看文案是 Saved 还是 Connected，再点一次看走 connect 还是 disconnect
看到 autoConnect 日志就判自动连接生效必须继续找 HFP service.connect、bt_btif_queue、ACL；触发与建链是两个阶段
把 Bluetooth death 全当崩溃用户 toggle OFF/ON 也会产生正常 binder death；先看前后是否有 turnOn false/true
把 UNAVAILABLE 当真门开结合车速/其他车门日志判断；信号冻结时 UNAVAILABLE 是幻影门开
抓日志只信主 txtmilog 轮转 FS/data/milog/logcat/*.gz 常藏关键窗口；蓝牙还要查 btsnoop（本案 hci1 恰好因权限写不进）

7. 本案最终处置建议

  • 主单:转 MiCarBluetoothService/车控信号链，修 Door.STATE UNAVAILABLE 与代理 fail-closed 门控；Settings 不改。
  • 另案 P0:转平台蓝牙栈，修 snoop_logger.cc:1481 FATAL 与 hci1 ownership/SELinux。
  • JIRA 字段:对 Settings UI 可维持「误报」，但处置说明必须写明存在两个真实缺陷，避免整单按无问题关闭。

8. 关联产物

  • 案件完整分析:车机JIRA/jira-data/MIICOSBUG-4733/analysis/root-cause.md
  • TSP 日志时间线:.../analysis/tsp-log-evidence.json
  • 三轮红队:.../analysis/review.json

Graph View