Quartz 4

🔍 搜索

40 · WLAN 排障速查:现象 → 先看哪里

10 min read

40 · WLAN 排障速查:现象 → 先看哪里

适用范围:车机 WLAN 单的入口文档。方法论 = 三层定位(框架 WifiService / 库 WifiTrackerLib / App Controller),先定层再深入;每层有对应深挖文档。 案例卡全部来自本地已完成对抗验证的根因分析(路径见各卡),代码事实与 30~34 篇同基线。

0. 三层定位法

flowchart TD
    SYM[WLAN 问题] --> Q1{哪一层的现象?}
    Q1 -->|"连不上/被踢/断流<br/>(列表状态都如实显示)"| L1[框架层:WifiService/wpa_supplicant<br/>dumpsys wifi + logcat reason code]
    Q1 -->|"条目错/闪/残留/排序怪<br/>(连接本身正常)"| L2[库层:WifiTrackerLib<br/>verbose log + WifiEntry.toString]
    Q1 -->|"文案/弹窗/按钮行为怪"| L3[App层:Controller/Preference<br/>MLog + 资源映射]
    L2 --> NOTE[问三个问题:<br/>①来了几波广播?<br/>②每波后 entry 什么状态?<br/>③UI 哪一波重建的?]

必带工具:

  • adb shell setprop log.tag.WifiPickerTracker VERBOSE(库 verbose,每条 entry 明细 WifiEntry.toString,WifiEntry.java:1557-1616)
  • dumpsys wifi(框架侧连接状态机/reason)
  • bugreport 284 日志(车机 JIRA 标配,见飞书知识库)

1. 现象速查表(机制 → 深挖文档)

现象先看详见
列表不刷新/不扫描shouldScan() 四条件(BaseWifiTracker:1073-1076,A17 灭屏=不扫;A14 无此 gate);isAppVisible 日志(:1122-1132);10s 周期21 §1.4
条目闪现/闪没ScanResultUpdater 15s/5min 双窗 + guardTransientEmpty 500ms + handleOnStart 清建顺序21 §5、32 §5
删除后残留/延迟无乐观移除 + binder 往返 + scan throttle;竞态窗口 A/B34
同 SSID 两条/少一条ScanResultKey 安全族合并(PSK↔SAE 一条)+ updateWifiEntries 5 层过滤21 §2.4
信号格数异常miuiCalculateSignalLevel 云控阈值(2.4G{-91,-77,-65}/5G{-91,-79,-65});连接态用 WifiInfo rssi、未连用最强 BSSID21 §3.2
连接无反馈NO_CONFIG→密码框;SUCCESS 等 L3;错密码→shouldEditBeforeConnect33 §5
”已保存”分组错isSaved=有 config 非建议非临时;不在范围的已保存网不显示32 §3
开关行为怪唯一 setWifiEnabled 点;三层防抖;loading 互斥31 §1
详情页状态不刷新详情页共享列表页 entry 引用,列表页 tracker onStop 即停21 §7
A14 vs A17 行为不一致flavor 五差异(广播时序/扫描 gate/5min 兜底/handleOnStart reason/锁)22
打开页面内容空窗数秒(骨架秒出)handleOnStart 串行 binder 风暴 × CPU 负载 × AP 密度三因子;先用 Performance_Monitor 数 IWifiManager 次数(单开页 451 次/3.83s)卡 6

2. 案例卡(已定案,可当判定模板)

卡 1:N801PROB-131987 — 删除已连接 AP 后列表清空 ~1s

  • 现象:forget 已连接 AP 后整表白屏 0.8-0.9s 再恢复。
  • 根因:forget 触发断连 → tracker 侧 scan 数据瞬间为空 → updateStandardWifiEntryScans 将全部断开 entry 置 UNREACHABLE 并 removeIf 清空 → getWifiEntries() 空 → MiCarAvailableWifiListController.updateState 无条件 removeAll 且无”空列表保留上一帧”防护。
  • 后续:已加 guardTransientEmpty(500ms 延迟复核,commit 7e1970bee)兜住同类空波;但 Provision 页无此防护。
  • 分析:车机JIRA/jira-data/N801PROB-131987/analysis/root-cause.md(high,代码+日志+负面对照三重闭环)

卡 2:MIICOSBUG-2782 — 海外 27B 删网后列表延迟(≠131987)

  • 现象:删除已连接网络后列表刷新延迟 ~1s。
  • 根因:第一次 CONFIGURED_NETWORKS_CHANGED(22ms)用缓存旧 scan 重算(内容陈旧);新 startScan 受系统 scan throttle(7879ms defer 波动)9291427ms 后第二波才刷新;叠加 2.4G/5G 双 SSID 异步迁移(forget 2.4G 后 +1s 开始 CONNECTING 5G)。
  • 教训:同一表象两种根因——131987 是”空波清屏”,2782 是”旧值残留+throttle 窗口”,先看”列表是变空了还是内容旧了”再定方向。
  • 分析:jira-data/MIICOSBUG-2782/analysis/root-cause.md

卡 3:MANNPROB-3405 — 错误密码无提示

  • 现象:输错密码连接,用户长时间无反馈。
  • 根因(v2 重分析):用户点的是已保存错误密码 entry,App 未实现 EditBeforeConnect 拦截 → 静默拿旧密码重连 → framework 判定延迟 13~17s;旧版”呈现层级不足”归因部分被推翻。
  • 修复:shouldEditBeforeConnect 命中直接弹密码框带”密码错误”红字(commit 43313d80d)。
  • 教训:反馈链有 4 层(inline 小字/框架失败广播/再点直弹/无 UI 的 UNKNOWN)——排”无反馈”先确定用户走的是哪条入口。
  • 分析:jira-data/MANNPROB-3405/analysis/root-cause.md

卡 4:MANNPROB-3907 — WLAN 连 Lemans 失败(App 无责,转 BSP)

  • 现象:27B 台架无法连接 Lemans 车型 WLAN,显示连接失败。
  • 根因:SAE(WPA3)握手成功 + AP 接受关联后,post-assoc 阶段被 reason=13(Invalid IE)踢断——AP/STA 侧信息元素协商问题,BSP/底层域。
  • 教训(判读铁律):判 SAE 成没成要看认证方式数值(key_mgmt),不能只看日志标签;App 层连接链路无异常时果断转层。
  • 分析:jira-data/MANNPROB-3907/analysis/root-cause.md

卡 5:N801PROB-137881 — monkey 下 WLAN 页 ANR

  • 现象:monkey 压测 WLAN 页 no-focused-window ANR。
  • 根因:主因 = monkey 未设 AVM 白名单,ActivityController 持续 reject com.mi.car.avm 启动(13 次)致焦点悬空,尾部超窗 ~2s——即使 App 完全空闲也会 ANR;WLAN 页自身的问题是伴生放大器(列表重建风暴)。
  • 深挖:WLAN列表重建风暴与ANR机制详解(617 行,机制教学完整版)
  • 分析:jira-data/N801PROB-137881/analysis/root-cause.md

卡 6:MIICOSBUG-2759 — 打开 WLAN 页内容显示过慢(空窗 3~6s)

  • 现象:骨架(标题/开关/分组标头)0.5s 秒出,已连接卡片+可用列表空窗 3.2~6s,10/10 必现(faraday_eu A14、RF 实验室 49~81 AP、开机后高负载窗口)。
  • 根因(三因子乘积,主责车设 App):①结构缺陷=每开页全量重建 tracker(MiCarWifiListFragment.kt:74 无复用,三次开页线程 ID 各异)+ handleOnStart O(AP 数)×串行同步 binder 风暴(每 entry 810 次,其中 isWifiStandardSupported 是设备常量却逐 entry 查≤4 次,WifiEntry.java:287→1326)+ 15s 新鲜窗 UNREACHABLE 过滤双列表置空(MiWifiTrackerUtils.isNeedAddInList:122-134);②CPU 负载(开机高负载把单跳 binder 从 0.16ms 拉到 629ms);③AP 密度(实验室把逐 entry 缺陷放大 5~8 倍)。
  • 铁证:单开页 451 次 IWifiManager/净 3.83s ≈ handleOnStart 全程 4.67s;三方对照定责——fermi(快)/XCD A14(2.9s)/faraday(36s)同族代码同架构风暴(fermi 甚至 2879 次),底层服务端每次仅 120930µs 无故障 → 修复全部可在车设侧完成(常量缓存/快照先渲染/tracker 复用/锁内禁 binder/首扫提前 6 项)。
  • 教训:①”骨架快内容慢”= 内容首刷被 O(N)×串行 IPC 门控,排障先数 binder 次数;②快样本要查”是不是用空换的”(open#9 336ms 假快=扫描过期→零 entry→零风暴);③主 txt 的 V 级日志有轮转缺口,milog 归档才是全量(zcat 读);④标题平台标签(A17)可能是误填,以 build 指纹为准(实为 A14)。
  • 分析:jira-data/MIICOSBUG-2759/analysis/root-cause.md(high;录屏逐帧+milog 复测+Perfetto×2+三方对照+双 AI 交叉复核;配套 11-车设页面搭建入门 讲 UI 侧落点)

相邻域:热点(Hotspot)问题不在本库范围(热点走 MicarSoftAp/HotspotUtils,见 31 §6);热点改名致永久关闭的 141101 案例见 jira-data/MICOCKPIT-141101/analysis/root-cause.md。

3. 日志锚点速查(grep 即用)

锚点出处含义
d-confirm connect(...) when mis:ConnectionUtils(蓝牙域,勿混)—
"cache device status: isBusy:"MiCarBluetoothBondedDevicePreference(蓝牙域)—
onProfileStateChanged: profileCachedBluetoothDevice(蓝牙域)—
Scan loop called even though...BaseWifiTracker:1122-1132进程不可见仍被调度(异常时看)
Connect to profile : ... timeoutCachedBluetoothDevice(蓝牙域)—
fail to connect wifiMiCarBaseWifiEntryController:331-333CONNECT_STATUS_FAILURE_UNKNOWN(无 UI,纯日志)
WifiPickerTracker verbose 每条 entryWifiEntry.toString:1557-1616条目全字段快照(排列表错乱第一利器)
micar.intent.action.WIFI_CONNECTION_FAILURE框架→WifiSettingsActivity:42认证失败重弹密码框(发送方在框架)

4. 待验证清单(调研中标 [待验证] 汇总)

  1. ROM 是否提供 SharedConnectivityManager(KnownNetworkEntry/HotspotNetworkEntry 可达性);
  2. startScan 对 system uid 的实际限频策略(2782 实测有 7879ms defer,机制在框架);
  3. SLAVE_RSSI_CHANGED 注册无分支(死过滤项)来历;
  4. A17 上 isAtLeastB()(决定 wifi 开关态走 listener 还是广播);
  5. 框架侧 forget 后三路事件顺序(需 bugreport logcat 实证);
  6. micar.intent.action.WIFI_CONNECTION_FAILURE 的框架触发条件与 reason 集合;
  7. 现网有无 Passpoint/Specifier 场景。

Graph View