ワイヤレス Android Auto が走行中に繰り返し「切れて再び繋がる」症状の実際の原因と、実際に試した対策がそれぞれどんな効果を出したかを実測でまとめた文書。Samsung Galaxy(Android 16 / One UI 8.5)+ Audi(Android Automotive ベースの MMI)の組み合わせ事例。
要点 — 原因は一つに固まらなかった。走行のたびに別の要因が現れた。 ① 最初は Wi-Fi リンク断(WPA3/SAE 認証失敗の嵐)が主因で、保存済みの車載 Wi-Fi を削除すると認証失敗が 1日14回 → 0回に止まった(データで確定、以後も維持)。② Wi-Fi が静かになった後に残った再起動は メモリ圧迫で OS の LMK(Low Memory Killer)が稼働中の AA プロセスを回収するように見えた(7/13)。しかし その後の2回の走行(7/14・7/29)ではメモリ回収が再現しなかった。 ③ 最近実際に捉えた切断はほとんど Wi-Fi の電波が弱くて(ビーコン喪失 −89〜−92dBm)起きたもので、その多くは単に 駐車時に切れた正常終了 だった。→ だから次の対策は 電波側 を先に見る。
下の「診断」コマンドはすべて**読み取り専用(照会)**である。デバイスを変更しない。対策(保存ネットワーク削除・設定変更など)は別セクションで、各自の判断で実行する。
体感は「スマホが落ちて再起動」だが、実際は二つのどちらかだ。(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 がなぜ 125 でなく 300 で記録されるかは根拠未確保 — 「観測上 300」としてのみ扱う。)
① Android 16 WPA3/SAE 認証リグレッション(1段階目の主因 — 解消済み)
決定的シグネチャ:失敗が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 をアドバタイズするかは車の隣で1回スキャン(診断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分のギャップ → 直接の kill というより、別のトリガーで落ちた後の別個の回収だった可能性が残る。ⓒ 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 ハンドオフが重なりうる。→ 詳細な実測は下の 後続観測 節を参照。
③(メモリ回収)を有力と見た後、さらに2回走行ログを取った。ところが メモリ kill のシグネチャが再び現れなかった。 代わりに二度とも 車載 Wi-Fi の電波が弱くて 切れた側に近かった。
走行終了の頃にセッションが切れた。ログの順序が重要だ:プロジェクション画面が 先に 片付けられ → その後 Wi-Fi が切れた(beaconLoss rssi=-89)。メモリ回収は最後に起き、すでにキャッシュ(CACHED)状態のプロセスを片付ける後始末だった。 つまり ③ の「メモリが生きているセッションを殺す」とは 順序が正反対だ。 −89dBm は車内の座席では出ない弱い値で(通常 −40〜−65dBm)、再接続の試みも無かった → 正常な駐車終了と見る。
「09:40〜09:50 に再起動が集中した」との申告をログで確認した。3件で確定する。
| 順 | 切断 | 復旧 | 間隔 | 正体 |
|---|---|---|---|---|
| 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 の電波が特に弱かったという意味だ。新しいバグではなく、この日の走行の電波状況で説明できる。変わった構図:原因は一つに固まらず走行ごとに違った。Wi-Fi 認証(①)は保存ネットワーク削除で確実に消した。メモリ回収(③)は 7/13 には有力だったが、その後の2回の走行では現れなかった。最近実際に捉えた切断は 電波が弱くて(ビーコン喪失・信号測定失敗)起き、多くは駐車終了だった。だから次の対策は 電波側 を先に見る。
一度に一つだけ変えて数日走行し再発を観察するやり方で一つずつ検証した。
設定 → 接続 → 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 経路とは別)。次の候補 |
| 累積結果 | — | 1段階目(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) 車の隣で1回 — 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 再接続ループ(1段階目) | 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 バグ | versionName ≥ 26.22 |
除外(既に上回る) |
範囲の注意:各走行の分析は ログにセッション境界が残ったものだけ を説明する。負荷の高い機種でバッファがすぐ上書きされるため、捕捉できなかった切断もある。