A field write-up of what actually causes wireless Android Auto to repeatedly "drop and come back" mid-drive, and what measured effect each attempted fix had. Case: Samsung Galaxy (Android 16 / One UI 8.5) + Audi (Android Automotive-based MMI).
Key point — the cause never settled on one thing. A different factor showed up on each drive. ① At first the main driver was a Wi-Fi link drop (a WPA3/SAE authentication-failure storm); deleting the saved car Wi-Fi cut auth failures from 14/day to 0 (confirmed by data, still holds). ② The restarts left after Wi-Fi went quiet looked like memory pressure making the OS Low Memory Killer (LMK) reap the active AA process (7/13). But the memory kill did not appear again on the next two drives (7/14 & 7/29). ③ The drops actually captured lately were mostly from weak Wi-Fi signal (beacon loss, −89 to −92dBm), and many were just normal shutdowns while parking. → So the next fixes look at RF first.
Every "diagnosis" command below is read-only. It does not change the device. Fixes (deleting the saved network, changing settings) are in a separate section — apply them at your own discretion.
It feels like "the phone died and restarted," but it is actually one of two things. (a) The car's 5GHz hotspot link drops and the AA session restarts, or (b) memory pressure reaps an AA process and the session collapses. It is not an app crash — every gearhead (com.google.android.projection.gearhead) exit across the whole period has a non-crash reason (reason=3 LOW_MEMORY, some reason=14 FREEZER; reason=4/5/6 = APP_CRASH/NATIVE_CRASH/ANR is 0).
# Exit reason / importance — crash (reason=4/6) vs memory reap (reason=3)
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
# Surge of car-AP connection events / auth failures
adb shell dumpsys wifi | grep -i "<car-AP-SSID>"
⚠️ Discriminator correction (important). The rule "an active session shows importance
100/125(FOREGROUND), so300(SERVICE)/400(CACHED) exits are all harmless cache reaps" is inaccurate for wireless AA. A wireless AA session does not run on the notification/FGS-holding main process alone; it also needs helper processes (adj ~300) like:projection/:car. In practice, what memory pressure reaped were exactly these helpers (imp 300/400) — there was no main-FGS (imp 125) death recorded — yet the session can still drop. So instead of "no 100/125, therefore safe," you must also check for helper LOW_MEMORY reaps inside the session window. (Why the helper shows as 300 rather than 125 is not established — treat it as "observed 300" only.)
① Android 16 WPA3/SAE authentication regression (phase-1 main driver — resolved)
Decisive signature: failure isAUTHENTICATION_FAILURE reason=3:WRONG_PSWD+supplicantStateChangeEvents:{ ASSOCIATING }+ASSOCIATION_REJECTION status=1. The password is correct (the dedicated specifier path succeeded 134 times since boot), yet it fails before association. Under WPA2 the password is verified after association in the 4-way handshake, so a "wrong password" cannot occur at this stage. Only SAE (WPA3) uses the password in the Authentication frame before association → the failure point matches SAE negotiation failure exactly. The saved profile wasKeyMgmt: SAE+IsAddedByAutoUpgrade: true(WPA2→WPA3 auto-upgrade).
Caution (unconfirmed): the storm stopping when the saved network was deleted strongly supports "the SAE auto-upgraded saved profile was the driver," but does not prove "the AP is WPA3." Even a WPA2-only AP can produce the same symptom if the saved profile forces SAE (KeyMgmt:SAE,RequirePmf:true) and negotiation mismatches. Whether the AP actually advertises SAE must be confirmed with a single scan next to the car (diagnosis #5).
② Saved-network contention (same body as ①)
The car AP was also registered as an ordinary saved network, so system auto-connect (saved network) and the AA-only connection (specifier) contended over the same AP. The SAE auto-upgrade was attached to exactly this saved profile → deleting the saved network makes ① and ② vanish together.
③ Memory pressure → LMK reaping an active helper (likely on 7/13, not reproduced since)
Once the leading candidate for the restarts that remained after the Wi-Fi issue was gone. Many large resident apps push free memory below 1GB and keep swap in constant use. Under that pressure, a correlation was observed of Samsung LMK reaping the SERVICE-class (imp 300):projectionhelper:22:05 :projection reason=3 LOW_MEMORY reaped → 22:09 session collapse → 22:12 reconnect(a drop→restart within 3.5 min). RAM Plus only adds swap and does not protect adj-300 processes, so it did not stop this.
Limits (honesty): ⓐ the same signature (a:projection300 reap inside the session window) also appears on normally-ended sessions, so it cannot be distinguished from a teardown side-effect. ⓑ there is a 3.5-min gap between the reap (22:05) and the collapse (22:09) → rather than a direct kill, another trigger may have dropped it and the reap was a separate event. ⓒ main-FGS survival is unconfirmed. → this was "supported," not "confirmed," and as the Follow-up section below shows, the signature did not reproduce on the 7/14 & 7/29 drives.
④ Wi-Fi signal fade / beacon loss (RF — promoted by recent measurements)
Drops that happen with no auth-failure trace. At first this was seen only as "rare residual," but in the 7/14 & 7/29 logs most of the drops actually captured lately were this type. Signals:Conn.Personalizer determineBeaconLossDisconnection rssi=-89~-92(beacon loss),NETWORK_DISCONNECTION_EVENT locallyGenerated=false(the car AP drops first),wificond: Failed to get Signal Strength(signal-read failure). −89 to −92dBm is far too weak for a cabin seat, which fits a parking / getting-out situation. Brief mid-drive drop-and-recover flaps also showed up alongside this signal weakening. An AP-side rejection (status=1) or a BT↔Wi-Fi handoff may overlap. → see the Follow-up observations section below for details.
After treating ③ (memory reap) as the lead, we captured two more drives. The memory-kill signature did not show up again. Both times, the drop looked closer to weak car Wi-Fi signal.
The session dropped around the end of the drive. The order in the log matters: the projection screen was torn down first, then Wi-Fi dropped (beaconLoss rssi=-89). The memory reap came last, and it was cleanup of a process that was already CACHED. That is the opposite order of ③'s "memory kills a live session." −89dBm is far too weak for a cabin seat (usually −40 to −65dBm), and there was no reconnect attempt → we read it as a normal parking shutdown.
The report "restarts clustered at 09:40-09:50" was confirmed in the logs. Three events:
| # | Drop | Recover | Gap | What it was |
|---|---|---|---|---|
| 1 | 09:42:07 | 09:42:19 | 12s | session re-negotiation, self-recovered |
| 2 | 09:47:28 | 09:47:31 | 2.2s | preceded by wificond: Failed to get Signal Strength (weak signal) → brief drop and recover |
| final | 09:49:59 | none | — | car AP dropped first (locallyGenerated=false, rssi=-92) → switched to home Wi-Fi = parked |
GhLifecycleService restart. Those would always be left behind if a memory reap had killed it.Failed to get Signal Strength repeated at 10-second intervals around 09:47. That means the car Wi-Fi signal was especially weak on that stretch. Not a new bug — just the RF conditions of that drive.The revised picture: the cause never settled on one thing — it changed drive to drive. Wi-Fi auth (①) was turned off for good by deleting the saved network. Memory reap (③) looked likely on 7/13 but did not appear in the next two drives. The drops actually captured lately came from weak signal (beacon loss / signal-read failure), mostly at parking. So the next fixes should look at RF first.
Each was verified one at a time — change one thing, then drive for a few days watching for recurrence.
Settings → Connections → Wi-Fi → ⋮ → Saved networks → <car AP> → Delete
WifiNetworkSpecifier) using credentials received over Bluetooth, so it keeps working after deletion. To revert, just reconnect and enter the password.Disable Android Auto inside Secure Folder (enabled=DISABLED_USER).
Raise via Device care → Memory → RAM Plus.
:projection was still reaped under memory pressure and restarts occurred. Load average was also roughly unchanged before/after the increase (little pressure relief).Settings → Apps → Android Auto → Battery → "Unrestricted"
Device care → remove Android Auto, Google Play Services, and the nav app from the Sleeping / Deep-sleeping apps lists
What it actually does: this blocks Samsung's forced-stop path via app sleep / Doze. That is a separate path from the diagnosed lmkd memory-pressure reap, so setting a memory exception does not guarantee LMK reaps are stopped. Still, it is the most widely recommended fix online for wireless AA repeated disconnects and has no downside, so it is worth trying first. (Effect not yet measured on this device.)
| Fix | Cause addressed | Measured effect |
|---|---|---|
| A. Delete saved network | ① · ② | SAE auth failures 14/day → 0 (held) |
| B. Secure Folder AA off | ③ | duplicate gearhead thrashing removed |
| C. RAM Plus 12GB | ③ | limited — did not stop helper reap, little pressure relief. Revert & compare |
| D. AA optimization exception | (adjacent to ③) | not applied — blocks app-sleep/Doze path (separate from LMK path). Next candidate |
| Cumulative | — | Phase 1 (Wi-Fi auth) gone (confirmed). Memory reap (③) not reproduced on 7/14 & 7/29. Recent drops were mostly signal fade / parking (④) |
# 1) Reboot check — did the phone actually die
adb shell uptime; adb shell getprop ro.boot.bootreason
# 2) AA exit reason / importance — crash vs memory reap
# (a :projection reason=3 reap inside the session window is a likely collapse signal,
# but note it also appears on normally-ended sessions)
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
# 3) Car-AP connection events / failure reasons — reconnect storm / auth failure
adb shell dumpsys wifi | grep -i "<car-AP-SSID>"
# 4) Was the saved profile SAE auto-upgraded
adb shell dumpsys wifi | grep -iE "SAE|IsAddedByAutoUpgrade|RequirePmf"
# 5) Once, next to the car — does the AP actually advertise WPA3 (SAE)? (confirms ①)
adb shell cmd wifi list-scan-results | grep -i "<car-AP-SSID>"
# 6) Memory pressure — free memory, swap, load
adb shell cat /proc/meminfo | grep -E "MemFree|MemAvailable|SwapTotal|SwapFree"
adb shell uptime # load average
# 7) Did it drop on RF — beacon loss / AP-side drop / signal-read failure (cause ④)
adb shell dumpsys wifi | grep -iE "determineBeaconLoss|NETWORK_DISCONNECTION|locallyGenerated"
# + track session boundaries with CDM isAppeared: false=drop, true=resume
adb logcat -b system -d | grep -iE "isAppeared|WirelessStartup|wirelessDisconnected"
# 8) Order at the moment of the drop — deauth/beacon-loss vs LMK kill, which comes first
adb logcat -b main -G 16M # enlarge buffer before driving (cap caveat below)
adb logcat -b main -d > drive.log # dump right after driving
[SAE] / [RSN-SAE] / [MFPR] → WPA3 advertised, ① confirmed. Only [WPA2-PSK-CCMP-128] → SAE rejected.rssi just before the drop is below −85dBm or locallyGenerated=false, cause ④ (RF / parking shutdown) is the likelier read.To catch the deauth reason code / beacon loss / LMK kill logs at the moment of a drop, the main logcat buffer is small (a few MiB by default, ~tens of minutes) and overwrites fast. Enlarge it before the next drive (#8), and dump with -d right after (not streaming).
⚠️ Some devices won't grow the buffer. This device (Samsung / Android 16) caps the buffer at 5 MiB even if you pass
-G 16M("MAX log buffer size is 5 MiB"). Under high load, 5 MiB is still only a few minutes, so it's easy to miss the drive window. Options: (a) dump right after the drive, or (b) keep the phone connected and log to a file live during the whole drive withadb logcat -b main,system -v time > drive.log. On 7/29 the main buffer was already overwritten; only the longer-livedsystembuffer saved the window → capturesystemtoo.
Logs/screenshots pulled from the device contain personal/device identifiers (SSID/BSSID/BT address/accounts). Mask them before sharing/publishing.
| Item | How judged | Result in this case |
|---|---|---|
| AA app crash | exit-info reason=4/6 |
None (all exits non-crash: LOW_MEMORY/FREEZER) |
| Phone reboot | uptime / bootreason |
None |
| Wi-Fi reconnect loop (phase 1) | surge of connection events in dumpsys wifi |
Confirmed → gone via fix A (0, confirmed) |
| WPA3/SAE auth failure | failure at ASSOCIATING + status=1 |
Likely → gone (AP SAE advertisement unconfirmed). Still 0 on 7/29 |
| Saved-network contention | saved profile SAE auto-upgrade | Confirmed → resolved via fix A |
| Memory pressure → LMK reap | :projection reason=3 inside session window |
7/13 likely (unproven) → not reproduced on 7/14 & 7/29 |
| Wi-Fi signal fade / beacon loss (RF) | beaconLoss rssi, NETWORK_DISCONNECTION locallyGenerated=false, Failed to get Signal Strength |
Measured 7/14 & 7/29 — what recent drops were (−89 to −92dBm). Mostly parking shutdown, some brief mid-drive flaps |
| GMS bug | versionName ≥ 26.22 |
Ruled out (already past it) |
Scope caution: each drive's analysis explains only the events whose session boundaries were left in the logs. On this busy device the buffer overwrites fast, so some drops were not captured.