一份实测文档，记录无线 Android Auto 在行车中反复"断开又重连"的真实原因，以及亲自尝试的各项措施分别产生了什么实测效果。案例：Samsung Galaxy（Android 16 / One UI 8.5）+ Audi（基于 Android Automotive 的 MMI）。
要点 — 原因并未固定为一种。每次行车都出现不同的因素。 ① 起初主因是 Wi-Fi 链路断开（WPA3/SAE 认证失败风暴）；删除已保存的车载 Wi-Fi 后，认证失败从每天 14 次降到 0 次（数据已确认，至今保持）。② Wi-Fi 平息后残留的重启看似是 内存压力导致系统的 LMK（Low Memory Killer）回收活动中的 AA 进程（7/13）。但 在随后两次行车（7/14 与 7/29）中，内存击杀没有再出现。 ③ 最近实际捕获的断开大多来自 Wi-Fi 信号弱（信标丢失 −89 至 −92dBm），且很多只是 停车时的正常关闭。 → 因此下一步措施先看 射频（RF）侧。
下面的"诊断"命令全部为只读（查询），不会更改设备。措施（删除已保存网络、更改设置等）在单独一节，请自行判断后执行。
体感像"手机死机重启"，但实际是两者之一。(a) 车载 5GHz 热点链路断开，AA 会话重启；或 (b) 内存压力回收了 AA 进程，会话崩溃。并不是应用崩溃 — gearhead（com.google.android.projection.gearhead）的退出记录在整个时段都只有非崩溃原因（reason=3 LOW_MEMORY，部分 reason=14 FREEZER；reason=4/5/6 = APP_CRASH/NATIVE_CRASH/ANR 为 0 次）。
# 退出原因·importance — 崩溃（reason=4/6） vs 内存回收（reason=3） 的判别
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
# 车载 AP 连接事件激增·是否有认证失败
adb shell dumpsys wifi | grep -i "<车载AP_SSID>"
⚠️ 判别标准更正（重要）。 "活动会话以 importance
100/125（FOREGROUND）出现，因此300（SERVICE）/400（CACHED）的退出全都是无害的缓存回收"这一标准对无线 AA 并不准确。 无线 AA 会话并非只靠持有通知/FGS 的 main 进程运行，还需要:projection·:car这类 helper 进程（adj 300 级） 一起工作。实测中在内存压力下被回收的正是这些 helper（imp 300/400） — 并没有 main FGS（imp 125）的死亡记录 — 而会话仍可能断开。因此不是"没有 100/125 就安全"，而是必须同时检查会话打开的时间窗内 helper 的 LOW_MEMORY 回收。（helper 为何记为 300 而非 125 尚无依据 — 仅按"观测为 300"看待。）
① Android 16 WPA3/SAE 认证回归（第一阶段主因 — 已解决）
决定性特征：失败为AUTHENTICATION_FAILURE reason=3:WRONG_PSWD+supplicantStateChangeEvents:{ ASSOCIATING }+ASSOCIATION_REJECTION status=1。密码是对的（专用 specifier 路径自开机起成功 134 次），却在 association 之前 的阶段失败。若是 WPA2，密码在 association 之后 的 4-way handshake 中校验，因此这一阶段不可能出现"密码错误"。只有 SAE（WPA3）在 association 之前的 Authentication 帧中使用密码 → 失败点与 SAE 协商失败精确吻合。已保存的配置为KeyMgmt: SAE+IsAddedByAutoUpgrade: true（WPA2→WPA3 自动升级）。
注意（未证实）：删除已保存网络后风暴停止，强力支持"被 SAE 自动升级的已保存配置是主因"，但并不证明"AP 是 WPA3"。即使 AP 仅支持 WPA2，若已保存配置强制 SAE（KeyMgmt:SAE,RequirePmf:true）导致协商不匹配，也能产生相同症状。 AP 是否真的广播 SAE，需在车旁扫描一次（诊断第 5 项）来最终确认。
② 已保存网络争用（与①一体）
车载 AP 同时被注册为普通的已保存网络，于是系统自动连接（已保存网络）与 AA 专用连接（specifier）争用同一个 AP。SAE 自动升级正是附在这个已保存配置上 → 删除已保存网络一次即可让①·②同时消失。
③ 内存压力 → LMK 回收活动中的 helper（7/13 有力，此后未复现）
Wi-Fi 认证问题消失后残留重启的一度有力的候选。多个常驻大型应用把可用内存压到 1GB 以下并持续使用交换。在这种压力下，观测到 Samsung LMK 回收 SERVICE 级（imp 300）的:projectionhelper 的相关性：22:05 :projection reason=3 LOW_MEMORY 被回收 → 22:09 会话崩溃 → 22:12 重连（3.5 分钟内的断开→重启）。RAM Plus 只增加交换而不保护 adj-300 进程，因此未能阻止它。
局限（诚实说明）：ⓐ 同一特征（会话窗内:projection300 回收）在正常结束的会话中也会出现，与拆卸（teardown）的副作用无法区分。ⓑ 回收（22:05）与崩溃（22:09）之间存在 3.5 分钟间隔 → 与其说是直接击杀，不如说可能是别的触发使其掉线、回收是另一独立事件。ⓒ main FGS 是否存活未确认。→ 因此是**"支持"而非"证实"的程度；如下方"后续观测"所示，该特征在 7/14 与 7/29 的行车中未复现。**
④ Wi-Fi 信号弱 / 信标丢失（RF — 因近期实测而升级）
没有认证失败痕迹却断开的情况。最初只当作"少见的残留"，但在 7/14 与 7/29 的行车日志中 最近实际捕获的断开大多是这一类型。 信号：Conn.Personalizer determineBeaconLossDisconnection rssi=-89~-92（信标丢失）、NETWORK_DISCONNECTION_EVENT locallyGenerated=false（车载 AP 先断）、wificond: Failed to get Signal Strength（信号读取失败）。−89 至 −92dBm 对座舱座位而言过弱，符合 停车 / 下车 的情形。行车中短暂断开又重连的 flap 也与这种信号减弱一起出现。可能叠加 AP 侧拒绝（status=1）或 BT↔Wi-Fi 切换。→ 详细实测见下方 后续观测 一节。
在把 ③（内存回收）视为主因之后，又采集了两次行车日志。然而 内存击杀的特征没有再出现。 两次都更接近 车载 Wi-Fi 信号弱 导致的断开。
会话在行车结束前后断开。日志的顺序很关键：projection 画面 先 被拆卸 → 然后 Wi-Fi 才断（beaconLoss rssi=-89）。内存回收发生在最后，是对已处于缓存（CACHED）状态进程的收尾清理。 这与 ③ 的"内存杀死活动会话"顺序正好相反。 −89dBm 对车内座位而言过弱（通常 −40 至 −65dBm），且没有重连尝试 → 判定为正常的停车关闭。
"重启集中在 09:40-09:50"的反馈已用日志确认。确定为三起：
| 序 | 断开 | 恢复 | 间隔 | 真相 |
|---|---|---|---|---|
| 1 | 09:42:07 | 09:42:19 | 12 秒 | 会话重新协商，自行恢复 |
| 2 | 09:47:28 | 09:47:31 | 2.2 秒 | 之前有 wificond: Failed to get Signal Strength（信号弱）→ 短暂断开并恢复 |
| 最终 | 09:49:59 | 无 | — | 车载 AP 先断（locallyGenerated=false, rssi=-92）→ 切换到家庭 Wi-Fi = 已停车 |
GhLifecycleService 重启日志。若是内存回收杀死，必定留下这些日志。Failed to get Signal Strength 在 09:47 前后以 10 秒间隔反复出现。这说明该路段车载 Wi-Fi 信号特别弱。不是新 bug，而是这天行车的射频状况所致。修正后的图景：原因并未固定为一种，而是每次行车都不同。Wi-Fi 认证（①）已通过删除已保存网络彻底关闭。内存回收（③）在 7/13 看似有力，但随后两次行车未出现。最近实际捕获的断开来自 信号弱（信标丢失 / 信号读取失败），且大多在停车时。因此下一步措施先看 射频侧。
一次只改一项，然后行车数天观察是否复发，逐项验证。
设置 → 连接 → Wi-Fi → ⋮ → 已保存的网络 → <车载 AP> → 删除
WifiNetworkSpecifier）直接连接，因此删除后仍正常工作。要还原，只需重新连接并输入密码。停用安全文件夹内的 Android Auto（enabled=DISABLED_USER）。
从 设备维护 → 内存 → RAM Plus 提升。
:projection 仍被回收并发生重启。提升前后负载（load average）也几乎不变（压力缓解甚微）。设置 → 应用 → Android Auto → 电池 → "不受限制（Unrestricted）"
设备维护 → 从省电（休眠应用）·深度休眠应用列表中排除 Android Auto·Google Play Services·导航应用
性质说明：此措施阻断 Samsung 的经由应用休眠 / Doze 的强制停止路径。这与所诊断的 lmkd 内存压力回收是不同的路径，因此仅设内存例外并不保证能阻止 LMK 回收。尽管如此，它是在线上针对无线 AA 反复断开最被广泛推荐的措施且无副作用，值得优先尝试。（本机尚未实测效果）
| 措施 | 对应原因 | 实测效果 |
|---|---|---|
| A. 删除已保存网络 | ① · ② | SAE 认证失败 14 次/天 → 0 次（保持） |
| B. 安全文件夹 AA off | ③ | 消除重复 gearhead 的 thrashing |
| C. RAM Plus 12GB | ③ | 有限 — 未能阻止 helper 回收，负载缓解甚微。建议还原对比 |
| D. AA 优化例外 | （③ 的相邻路径） | 未应用 — 阻断应用休眠/Doze 路径（与 LMK 路径不同）。下一个候选 |
| 累计结果 | — | 第一阶段（Wi-Fi 认证）已消除（确定）。内存回收（③）在 7/14 与 7/29 未复现。近期断开大多为信号弱 / 停车（④） |
# 1) 是否重启 — 手机是否真的死机
adb shell uptime; adb shell getprop ro.boot.bootreason
# 2) AA 退出原因·importance — 崩溃 vs 内存回收 的判别
# （会话时间窗内的 :projection reason=3 回收 = 会话崩溃的有力信号，但注意正常结束时也会出现）
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
# 3) 车载 AP 连接事件·失败原因 — 重连风暴/认证失败的确认
adb shell dumpsys wifi | grep -i "<车载AP_SSID>"
# 4) 已保存配置是否被 SAE 自动升级
adb shell dumpsys wifi | grep -iE "SAE|IsAddedByAutoUpgrade|RequirePmf"
# 5) 在车旁进行一次 — AP 是否真的广播 WPA3（SAE）（确认原因①）
adb shell cmd wifi list-scan-results | grep -i "<车载AP_SSID>"
# 6) 内存压力实测 — 可用内存·交换·负载
adb shell cat /proc/meminfo | grep -E "MemFree|MemAvailable|SwapTotal|SwapFree"
adb shell uptime # load average
# 7) 是否因射频断开 — 信标丢失 / AP 侧断开 / 信号读取失败（原因 ④）
adb shell dumpsys wifi | grep -iE "determineBeaconLoss|NETWORK_DISCONNECTION|locallyGenerated"
# + 用 CDM isAppeared 跟踪会话边界：false=断开，true=恢复
adb logcat -b system -d | grep -iE "isAppeared|WirelessStartup|wirelessDisconnected"
# 8) 确定掉线瞬间的先后 — deauth/信标丢失 vs LMK kill 谁先
adb logcat -b main -G 16M # 行车前扩大缓冲区（注意上限，见下）
adb logcat -b main -d > drive.log # 行车后立即导出
[SAE] / [RSN-SAE] / [MFPR] → 广播 WPA3，原因① 确定。仅 [WPA2-PSK-CCMP-128] → SAE 被否定。rssi 低于 −85dBm 或 locallyGenerated=false，则更可能是原因 ④（射频 / 停车关闭）。要抓住掉线瞬间的 deauth 原因码·信标丢失·LMK kill 日志，main logcat 缓冲区较小（默认数 MiB，约数十分钟量）会很快被覆盖。下次行车前先扩大（诊断第 8 项）。行车后立即用 -d 导出（非流式）。
⚠️ 有些设备无法增大缓冲区。 本设备（Samsung / Android 16）即使传入
-G 16M，缓冲区上限也固定为 5 MiB（"MAX log buffer size is 5 MiB"）。在高负载下，5 MiB 也只有几分钟，容易错过行车区间。可选方案：(a) 行车后立即导出；或 (b) 保持手机连接，用adb logcat -b main,system -v time > drive.log在整段行车中实时写入文件。7/29 时 main 缓冲区已被覆盖，多亏存留更久的system缓冲区才勉强捞到区间 → 建议连system一起采集。
从设备取出的日志·截图含有 SSID/BSSID/BT 地址/账号等个人·设备识别信息。共享·发布前请打码。
| 项目 | 判定方法 | 本案例结果 |
|---|---|---|
| AA 应用崩溃 | exit-info reason=4/6 |
无（退出原因全为非崩溃：LOW_MEMORY/FREEZER） |
| 手机重启 | uptime / bootreason |
无 |
| Wi-Fi 重连循环（第一阶段） | dumpsys wifi 连接事件激增 |
已确认 → 经措施 A 消除（0 次，确定） |
| WPA3/SAE 认证失败 | 失败点 ASSOCIATING + status=1 |
有力 → 消除（AP 的 SAE 广播未确定）。7/29 仍为 0 |
| 已保存网络争用 | 已保存配置的 SAE 自动升级 | 确认 → 经措施 A 解决 |
| 内存压力 → LMK 回收 | 会话窗内 :projection reason=3 |
7/13 有力（未证实）→ 7/14 与 7/29 未复现 |
| Wi-Fi 信号弱 / 信标丢失（RF） | beaconLoss rssi、NETWORK_DISCONNECTION locallyGenerated=false、Failed to get Signal Strength |
7/14 与 7/29 实测 — 近期断开的真相（−89 至 −92dBm）。大多为停车关闭，部分为行车中短暂 flap |
| GMS bug | versionName ≥ 26.22 |
排除（已高于） |
范围提醒：每次行车的分析仅解释 日志中留有会话边界的事件。 本设备繁忙，缓冲区很快被覆盖，因此有些断开未被捕获。