ワイヤレスAndroid Autoが走行中に繰り返し「切断されて再び起動する」症状をadbで診断する手順と、原因候補・対処候補を整理した文書である。多くの場合はアプリのクラッシュではなくWi-Fiリンクのドロップであり、外見上はどちらも同じく「AAが落ちて復帰する」ように見える。実際のSamsung Galaxy(Android 16 / One UI 8.5)+ Audi(Android AutomotiveベースのMMI)の組み合わせ事例を一般化した。
本文書のすべてのコマンドは**読み取り専用(参照)**である。デバイスを変更しない。
settings put、forget-network、pm clearなどの変更コマンドは「対処」セクションで別途扱い、ユーザーの判断で実行する。
ワイヤレスAAのユーザーが「スマホが異常終了して再起動する」と感じる現象は、たいてい次の3つのいずれかである。どれなのかをまず切り分けてこそ、見当違いの箇所を掘らずに済む。
| 体感する症状 | 実際の正体 | 確認方法 |
|---|---|---|
| AA画面が消えて再び表示される | Wi-Fiリンクのドロップ → AAセッション再起動(最も多い) | Wi-Fi接続イベントの急増 |
| AAアプリだけが落ちる | アプリのクラッシュ(reason=4)または ANR(reason=6) | exit-info にcrashの記録 |
| スマホ全体が再起動 | カーネルパニック / ウォッチドッグ | uptime、bootreason |
まずスマホが実際に再起動したかを確認する。
adb shell uptime
adb shell getprop ro.boot.bootreason
uptime が数日単位で維持され、bootreason が shutdown,userrequested(正常終了)であれば、スマホは再起動していない。 すると、アプリレベルまたはリンクレベルの問題に絞り込まれる。
exit-infoAndroid 11+ の ApplicationExitInfo はプロセスが終了した理由を残す。AAのパッケージは com.google.android.projection.gearhead である。
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
各記録の reason を見る。
| reason | 意味 | 解釈 |
|---|---|---|
4 (APP CRASH) |
Java例外によるクラッシュ | 本物のアプリのバグ。 スタックトレースを確保 |
6 (ANR) |
応答なし | アプリのハング |
3 (LOW_MEMORY) |
メモリ回収 | クラッシュではない。キャッシュの整理 |
5 (NATIVE CRASH) |
ネイティブクラッシュ | tombstone を確認 |
実際の事例では、AAの終了記録がすべて
reason=3 (LOW_MEMORY)であり、終了した時点でプロセスはすべてキャッシュ/サービス状態(importance 300~400)だった。つまりアクティブなAAセッション中に終了したのではなく、セッションが終わってキャッシュに落ちたプロセスが回収されたということ。 この場合、原因はAAアプリではない。
importance の値も併せて見る。100(FOREGROUND)/125(FOREGROUND_SERVICE)で終了したならアクティブセッションの終了だが、300(SERVICE)/400(CACHED)であれば、すでにバックグラウンドに落ちた後に整理されたものである。
クラッシュでなければWi-Fiリンクを見る。ワイヤレスAAは、車両が立てた5GHzホットスポットにスマホが接続してデータをやり取りする構造なので、このリンクが切れるとAAセッションも切れる。
# 車両APとの接続イベント履歴(成功/失敗、失敗理由を含む)
adb shell dumpsys wifi | grep -i "<車両AP_SSID>"
# supplicantの状態遷移タイムライン(associating↔disconnectedの反復を確認)
adb shell dumpsys batterystats --history | grep -iE "wifi_suppl|<車両AP_SSID>"
正常であれば走行1回につき接続1回であるべきだ。1回の走行で接続イベントが数十回記録され、supplicant が associating ↔ disconnected を秒単位で繰り返すなら、再接続ループに陥っている。
dumpsys wifi の接続失敗イベントにおいて、失敗した位置が核心的な手がかりである。
AUTHENTICATION_FAILURE_EVENT reason=3:ERROR_AUTH_FAILURE_WRONG_PSWD
supplicantStateChangeEvents: { ASSOCIATING }
ASSOCIATION_REJECTION_EVENT status=1:UNSPECIFIED_FAILURE
この組み合わせは、パスワードは正しいのに認証に失敗する特異なケースを指している。判別のポイント:
WRONG_PSWD が出るのに同じネットワークに普段は問題なく接続できる → パスワードは正常で、「wrong password」は誤検知である。ASSOCIATING(association完了の前)である。WPA2ならパスワードはassociationの後の4-way handshakeで検証されるため、この段階で「パスワードが違う」は起こり得ない。WPA3(SAE)はassociationの前のAuthenticationフレームでパスワードを使う → この失敗地点はSAE交渉の失敗と正確に一致する。保存されたネットワークプロファイルがWPA3として扱われているかを確認:
adb shell dumpsys wifi | grep -iE "SAE|IsAddedByAutoUpgrade|RequirePmf"
KeyMgmt: SAE + IsAddedByAutoUpgrade: true が見えれば、元々WPA2だったプロファイルをAndroidがWPA3へ自動昇格させた状態である。この自動昇格が一部のヘッドユニットとのSAE交渉で破綻していると疑われる。
車両の近くで1回実行する。この1行がSAE仮説を確定/棄却する。
adb shell cmd wifi list-scan-results | grep -i "<車両AP_SSID>"
[SAE] / [RSN-SAE] / [MFPR] → WPA3アドバタイズ。SAE仮説確定。[WPA2-PSK-CCMP-128][RSN-PSK-CCMP-128][ESS] のみ → WPA2専用。SAE仮説を棄却し、別の候補へ。2026-06-08、Google Play Services 26.22 に「Device Connection関連のバグ修正」が入り、ワイヤレスAA切断の解決策として広く報道された。まず、このスマホに既に反映されているかを確認する。
adb shell dumpsys package com.google.android.gms | grep versionName
バージョンが26.22以上でも症状が続くなら、その有名なバグは原因ではない。(実際の事例: 26.24以上でも再発 → 排除された)
証拠の強さ順に候補を列挙する。1つに断定せず、上記の診断で絞り込むこと。
① Android 16 の WPA3/SAE 認証リグレッション(最有力)
失敗がASSOCIATING段階 +status=1。同じAPに普段は接続できる。保存プロファイルがSAE自動昇格。→ Pixel/GalaxyのAndroid 16 + WPA3-SAE APの組み合わせで「パスワードは正しいのに認証失敗」が報告されたリグレッションとシグネチャが一致。
② ヘッドユニット(AP)側のセッション/ファームウェアの問題
status=1:UNSPECIFIED_FAILUREはAPが送った拒否コードである。ヘッドユニットが前のセッションのassociationを片付けられなかったか、ファームウェアが古い可能性がある。車両インフォテインメントのソフトウェアアップグレード後に切断が発生した先例もある。
③ Bluetoothの先行切断 → Wi-Fi切断
ワイヤレスAAはBT(ペアリング・オーディオ)+ Wi-Fi(データ)の組み合わせである。信号が良い(-30~-40dBm)のに切れるなら、RFの距離の問題ではなくBTスタックの問題かもしれない。最新のBT 5.4 / LE Audio関連の報告が多数。
④ 保存ネットワークの競合 /「不良Wi-Fiの回避」
車両APが通常の保存ネットワークとしても登録されると、システムの自動接続とAA専用接続が同じAPをめぐって競合する。network_avoid_bad_wifi=1であれば、インターネットのない車両APを回避しようとする。
⑤ メモリ圧迫(増幅要因であり、原因ではない)
RAM Plus(仮想メモリ)でアプリを終了させる代わりにzramへ押し込むと、リンク復旧時のAAプロセスのコールドスタート/スワップインが遅くなる。切断そのものを生むわけではないが、再起動を遅くする。
非破壊・可逆・低コストの順。 個人のデバイスなので、削除/設定変更は自分の判断で実行する。1つ変えて数日走行し、再発の有無を観察するかたちで、1つずつ検証することを勧める。
設定 → 接続 → Wi-Fi → ⋮ → 保存されたネットワーク → <車両AP> → 削除
WifiNetworkSpecifier)で直接接続するため、ワイヤレスAAは引き続き正常に動作する。 元に戻すには、再度接続してパスワードを入力すればよい。原因①が確定すれば、知られている確実な回避策はAPをWPA2専用に下げることである。車両MMIにWi-Fiセキュリティ設定が公開されているかを、マニュアル/ディーラーで確認する。
車両インフォテインメントのビルドが古ければ(セキュリティパッチの日付で確認)更新する。メーカーの更新ポータルまたはディーラー。
開発者オプション → Bluetooth LE Audio Mode → Disable の後、再起動。(付随的にA2DPハードウェアオフロードOFFの事例もある)
切断の瞬間のdeauth理由コードまで捉えるには、main logcatバッファが小さく(デフォルトで数MiB、十数分ぶん)すぐに上書きされる。次の走行前に拡大しておく。
adb logcat -b main -G 16M # バッファ拡大
# ... 走行して症状を再現 ...
adb logcat -b main -d > drive.log # 走行直後にダンプ(ストリーミングではない)
デバイスから取得したログ・スクリーンショットには、SSID/BSSID/BTアドレス/アカウントなど、個人・デバイスを識別する情報が含まれる。共有・公開の前にマスキングすること。
| 項目 | 判定方法 | 本事例の結果 |
|---|---|---|
| AAアプリのクラッシュ | exit-info reason=4/6 |
なし(すべてLOW_MEMORY) |
| スマホの再起動 | uptime / bootreason |
なし |
| Wi-Fi再接続ループ | dumpsys wifi の接続イベント急増 |
確認された |
| WPA3/SAE認証の失敗 | 失敗地点 ASSOCIATING + status=1 |
有力 |
| GMSバグ | versionName ≥ 26.22 |
排除(既に最新) |
| メモリ圧迫 | zram/loadavg | 増幅要因 |