This document lays out the procedure for using adb to diagnose the symptom of wireless Android Auto repeatedly "disconnecting and coming back on" while driving, along with candidate causes and candidate remedies. In most cases it is not an app crash but a Wi-Fi link drop, and on the surface it looks identical: "AA dies and comes back." It generalizes from a real-world case of a Samsung Galaxy (Android 16 / One UI 8.5) + Audi (Android Automotive–based MMI) combination.
All commands in this document are read-only (query). They do not modify the device. Mutating commands such as
settings put,forget-network, andpm clearare handled separately in the "Remedies" section and are executed at the user's discretion.
The phenomenon that wireless AA users perceive as "the phone crashes and then restarts" is usually one of three things. You must first identify which one so you don't dig in the wrong place.
| Perceived symptom | Actual cause | How to check |
|---|---|---|
| AA screen goes off and comes back | Wi-Fi link drop → AA session restart (most common) | Surge in Wi-Fi connection events |
| Only the AA app crashes out | App crash (reason=4) or ANR (reason=6) | crash record in exit-info |
| The whole phone reboots | Kernel panic / watchdog | uptime, bootreason |
First check whether the phone actually rebooted.
adb shell uptime
adb shell getprop ro.boot.bootreason
If uptime has held for days and bootreason is shutdown,userrequested (a normal shutdown), then the phone has never rebooted. That narrows it down to an app-level or link-level problem.
exit-infoAndroid 11+'s ApplicationExitInfo records the reason a process died. The AA package is com.google.android.projection.gearhead.
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
Look at the reason of each record.
| reason | Meaning | Interpretation |
|---|---|---|
4 (APP CRASH) |
Crash from a Java exception | A genuine app bug. Capture the stack trace |
6 (ANR) |
Not responding | App hang |
3 (LOW_MEMORY) |
Memory reclaim | Not a crash. Cache cleanup |
5 (NATIVE CRASH) |
Native crash | Check the tombstone |
In the real-world case, the AA termination records were all
reason=3 (LOW_MEMORY), and at the time of death the processes were all in a cached/service state (importance 300~400). In other words, it did not die during an active AA session; rather, a process that had dropped to cache after the session ended was reclaimed. In this case the cause is not the AA app.
Also look at the importance value. If it died at 100 (FOREGROUND)/125 (FOREGROUND_SERVICE), that is an active-session death, but 300 (SERVICE)/400 (CACHED) means it had already dropped to the background and was then cleaned up.
If it is not a crash, look at the Wi-Fi link. Wireless AA works by having the phone attach to a 5GHz hotspot raised by the car and exchange data over it, so if this link drops, the AA session drops too.
# Connection event history with the car AP (includes success/failure and failure reason)
adb shell dumpsys wifi | grep -i "<car_AP_SSID>"
# Supplicant state-transition timeline (check associating↔disconnected repetition)
adb shell dumpsys batterystats --history | grep -iE "wifi_suppl|<car_AP_SSID>"
In a healthy state it should be one connection per drive. If dozens of connection events are logged in a single drive and the supplicant repeats associating ↔ disconnected on the order of seconds, it has fallen into a reconnection loop.
In the connection-failure events from dumpsys wifi, where the failure occurs is the key clue.
AUTHENTICATION_FAILURE_EVENT reason=3:ERROR_AUTH_FAILURE_WRONG_PSWD
supplicantStateChangeEvents: { ASSOCIATING }
ASSOCIATION_REJECTION_EVENT status=1:UNSPECIFIED_FAILURE
This combination points to the unusual case where the password is correct but authentication fails. Discriminating points:
WRONG_PSWD appears, yet you normally connect to the same network just fine → the password is fine; the "wrong password" is a false positive.ASSOCIATING (before association completes). With WPA2, the password is verified in the 4-way handshake after association, so "wrong password" cannot occur at this stage. WPA3 (SAE) uses the password in the Authentication frame before association → this failure point aligns exactly with an SAE negotiation failure.Check whether the saved network profile is being treated as WPA3:
adb shell dumpsys wifi | grep -iE "SAE|IsAddedByAutoUpgrade|RequirePmf"
If you see KeyMgmt: SAE + IsAddedByAutoUpgrade: true, Android has auto-upgraded a profile that was originally WPA2 to WPA3. This auto-upgrade is suspected of breaking during SAE negotiation with some head units.
Run this once, near the car. This single line confirms or rejects the SAE hypothesis.
adb shell cmd wifi list-scan-results | grep -i "<car_AP_SSID>"
[SAE] / [RSN-SAE] / [MFPR] in Flags → WPA3 advertised. SAE hypothesis confirmed.[WPA2-PSK-CCMP-128][RSN-PSK-CCMP-128][ESS] → WPA2-only. SAE hypothesis rejected; move on to another candidate.On 2026-06-08, Google Play Services 26.22 included a "Device Connection–related bug fix," widely reported as the solution to wireless AA disconnections. First check whether it is already applied on this phone.
adb shell dumpsys package com.google.android.gms | grep versionName
If the version is 26.22 or higher and the symptom persists anyway, that famous bug is not the cause. (Real-world case: it recurred even on 26.24 or higher → ruled out.)
The candidates are listed in order of evidence strength. Don't jump to a single conclusion; narrow it down with the diagnostics above.
① Android 16 WPA3/SAE authentication regression (most likely)
Failure at theASSOCIATINGstage +status=1. Normally connects to the same AP. The saved profile is an SAE auto-upgrade. → The signature matches the reported regression of "password is right but authentication fails" on the Pixel/Galaxy Android 16 + WPA3-SAE AP combination.
② Head-unit (AP)–side session/firmware problem
status=1:UNSPECIFIED_FAILUREis a rejection code sent by the AP. The head unit may have failed to clear a prior session's association, or its firmware may be outdated. There are precedents where disconnections appeared after a vehicle infotainment software upgrade.
③ Bluetooth disconnects first → Wi-Fi disconnects
Wireless AA is a combination of BT (pairing/audio) + Wi-Fi (data). If it drops despite a good signal (-30 to -40 dBm), it may be a BT-stack problem rather than an RF-distance problem. Many reports relate to the latest BT 5.4 / LE Audio.
④ Saved-network contention / "avoid bad Wi-Fi"
If the car AP is also registered as an ordinary saved network, the system's auto-connect and AA's dedicated connection contend over the same AP. Withnetwork_avoid_bad_wifi=1, the system tries to avoid the internet-less car AP.
⑤ Memory pressure (an amplifying factor, not a cause)
When RAM Plus (virtual memory) pushes apps into zram instead of killing them, the AA process's cold start / swap-in becomes slow during link recovery. It doesn't create the disconnection itself, but it makes the restart slower.
In order of non-destructive, reversible, low-cost. Since this is a personal device, deletions/setting changes are executed at your own discretion. It is recommended to verify one at a time — change one thing, drive for a few days, and observe whether the symptom recurs.
Settings → Connections → Wi-Fi → ⋮ → Saved networks → <car AP> → Delete
WifiNetworkSpecifier), so wireless AA keeps working normally. To revert, just reconnect and enter the password.If cause ① is confirmed, the known definitive workaround is downgrading the AP to WPA2-only. Check via the manual/dealer whether the vehicle MMI exposes a Wi-Fi security setting.
If the vehicle infotainment build is old (check by the security-patch date), update it. Via the manufacturer's update portal or the dealer.
Developer options → Bluetooth LE Audio Mode → Disable, then reboot. (Incidentally, there are cases of also turning A2DP hardware offload OFF.)
To capture even the deauth reason code at the moment of disconnection, note that the main logcat buffer is small (a few MiB by default, a dozen-odd minutes' worth) and gets overwritten quickly. Enlarge it before your next drive.
adb logcat -b main -G 16M # Enlarge the buffer
# ... drive and reproduce the symptom ...
adb logcat -b main -d > drive.log # Dump right after driving (not streaming)
Logs/screenshots pulled from the device contain personal and device-identifying information such as SSID/BSSID/BT address/account. Mask them before sharing or publishing.
| Item | How to determine | Result in this case |
|---|---|---|
| AA app crash | exit-info reason=4/6 |
None (all LOW_MEMORY) |
| Phone reboot | uptime / bootreason |
None |
| Wi-Fi reconnection loop | Surge in dumpsys wifi connection events |
Confirmed |
| WPA3/SAE authentication failure | Failure point ASSOCIATING + status=1 |
Likely |
| GMS bug | versionName ≥ 26.22 |
Ruled out (already up to date) |
| Memory pressure | zram/loadavg | Amplifying factor |