Documento de campo sobre qué causa realmente que Android Auto inalámbrico se "desconecte y vuelva" repetidamente al conducir, y qué efecto medido tuvo cada solución probada. Caso: Samsung Galaxy (Android 16 / One UI 8.5) + Audi (MMI basado en Android Automotive).
Punto clave — la causa nunca se fijó en una sola. En cada trayecto apareció un factor distinto. ① Al principio el motor principal fue una caída del enlace Wi-Fi (una tormenta de fallos de autenticación WPA3/SAE); eliminar la red Wi-Fi del coche guardada redujo los fallos de autenticación de 14/día a 0 (confirmado con datos, aún se mantiene). ② Los reinicios que quedaron tras calmarse el Wi-Fi parecían presión de memoria haciendo que el Low Memory Killer (LMK) del sistema recolecte el proceso AA activo (7/13). Pero el kill por memoria no volvió a aparecer en los dos trayectos siguientes (7/14 y 7/29). ③ Las caídas realmente capturadas últimamente venían casi todas de señal Wi-Fi débil (pérdida de baliza, −89 a −92dBm), y muchas eran simples apagados normales al aparcar. → Así que las próximas soluciones miran primero al RF.
Todos los comandos de "diagnóstico" de abajo son de solo lectura. No modifican el dispositivo. Las soluciones (eliminar la red guardada, cambiar ajustes) van en una sección aparte — aplícalas a tu criterio.
Se siente como "el teléfono murió y se reinició", pero en realidad es una de dos cosas. (a) El enlace del hotspot de 5 GHz del coche cae y la sesión AA se reinicia, o (b) la presión de memoria recolecta un proceso AA y la sesión colapsa. No es un fallo (crash) de la app — cada salida de gearhead (com.google.android.projection.gearhead) en todo el periodo tiene una razón no de crash (reason=3 LOW_MEMORY, algunos reason=14 FREEZER; reason=4/5/6 = APP_CRASH/NATIVE_CRASH/ANR es 0).
# Razón de salida / importance — crash (reason=4/6) vs recolección por memoria (reason=3)
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
# Aumento de eventos de conexión al AP del coche / fallos de autenticación
adb shell dumpsys wifi | grep -i "<SSID-AP-coche>"
⚠️ Corrección del criterio de discriminación (importante). La regla "una sesión activa aparece con importance
100/125(FOREGROUND), así que las salidas300(SERVICE)/400(CACHED) son recolecciones de caché inofensivas" es inexacta para AA inalámbrico. Una sesión de AA inalámbrico no corre solo en el proceso principal que sostiene la notificación/FGS; también necesita procesos helper (adj ~300) como:projection/:car. En la práctica, lo que la presión de memoria recolectó fueron exactamente estos helpers (imp 300/400) — no se registró muerte del main-FGS (imp 125) — y aun así la sesión puede caer. Por tanto, en lugar de "no hay 100/125, luego es seguro", también debes comprobar recolecciones LOW_MEMORY de helpers dentro de la ventana de la sesión. (Por qué el helper aparece como 300 y no 125 no está establecido — trátalo solo como "300 observado".)
① Regresión de autenticación WPA3/SAE de Android 16 (motor principal de la fase 1 — resuelto)
Firma decisiva: el fallo esAUTHENTICATION_FAILURE reason=3:WRONG_PSWD+supplicantStateChangeEvents:{ ASSOCIATING }+ASSOCIATION_REJECTION status=1. La contraseña es correcta (la ruta dedicada por specifier tuvo 134 éxitos desde el arranque), pero falla antes de la asociación. En WPA2 la contraseña se verifica después de la asociación en el 4-way handshake, así que no puede darse "contraseña incorrecta" en esta etapa. Solo SAE (WPA3) usa la contraseña en el frame de Authentication antes de la asociación → el punto de fallo coincide exactamente con un fallo de negociación SAE. El perfil guardado eraKeyMgmt: SAE+IsAddedByAutoUpgrade: true(auto-actualización WPA2→WPA3).
Precaución (no confirmado): que la tormenta se detuviera al eliminar la red guardada respalda fuertemente que "el perfil guardado auto-actualizado a SAE fue el motor", pero no prueba que "el AP sea WPA3". Incluso un AP solo WPA2 puede producir el mismo síntoma si el perfil guardado fuerza SAE (KeyMgmt:SAE,RequirePmf:true) y la negociación no coincide. Si el AP realmente anuncia SAE debe confirmarse con un único escaneo junto al coche (diagnóstico n.º 5).
② Contención de red guardada (mismo cuerpo que ①)
El AP del coche también estaba registrado como red guardada normal, así que la conexión automática del sistema (red guardada) y la conexión exclusiva de AA (specifier) competían por el mismo AP. La auto-actualización SAE estaba adjunta justamente a este perfil guardado → eliminar la red guardada hace que ① y ② desaparezcan juntas.
③ Presión de memoria → LMK recolecta un helper activo (probable el 7/13, no reproducido desde entonces)
Fue el candidato principal para los reinicios que quedaron tras desaparecer el problema de Wi-Fi. Muchas apps residentes grandes empujan la memoria libre por debajo de 1 GB y mantienen el swap en uso constante. Bajo esa presión se observó una correlación de que el LMK de Samsung recolecta el helper:projectionde clase SERVICE (imp 300):22:05 :projection reason=3 LOW_MEMORY recolectado → 22:09 colapso de sesión → 22:12 reconexión(una caída→reinicio en 3,5 min). RAM Plus solo añade swap y no protege los procesos adj-300, así que no lo detuvo.
Límites (honestidad): ⓐ la misma firma (una recolección de:projection300 dentro de la ventana de sesión) también aparece en sesiones terminadas normalmente, así que no se distingue de un efecto colateral del cierre. ⓑ hay un hueco de 3,5 min entre la recolección (22:05) y el colapso (22:09) → en lugar de una muerte directa, otro disparador pudo tirarla y la recolección fue un evento aparte. ⓒ la supervivencia del main-FGS no está confirmada. → esto estaba "respaldado", no "confirmado", y como muestra la sección de Observaciones de seguimiento abajo, la firma no se reprodujo en los trayectos del 7/14 y 7/29.
④ Señal Wi-Fi débil / pérdida de baliza (RF — promovido por mediciones recientes)
Caídas que ocurren sin rastro de fallo de autenticación. Al principio esto se veía solo como "residual raro", pero en los logs del 7/14 y 7/29 la mayoría de las caídas realmente capturadas últimamente eran de este tipo. Señales:Conn.Personalizer determineBeaconLossDisconnection rssi=-89~-92(pérdida de baliza),NETWORK_DISCONNECTION_EVENT locallyGenerated=false(el AP del coche corta primero),wificond: Failed to get Signal Strength(fallo de lectura de señal). −89 a −92dBm es demasiado débil para un asiento de cabina, lo que encaja con una situación de aparcamiento / bajarse. También aparecieron flaps breves de caída-y-recuperación en marcha junto a este debilitamiento de señal. Puede solaparse un rechazo del lado del AP (status=1) o un traspaso BT↔Wi-Fi. → ver la sección Observaciones de seguimiento abajo para el detalle.
Tras tratar ③ (recolección por memoria) como la principal, capturamos dos trayectos más. La firma de kill por memoria no volvió a aparecer. Ambas veces, la caída se parecía más a señal Wi-Fi del coche débil.
La sesión cayó cerca del final del trayecto. El orden en el log importa: la pantalla de projection se desmontó primero, luego cayó el Wi-Fi (beaconLoss rssi=-89). La recolección por memoria vino al final, y fue limpieza de un proceso que ya estaba CACHED. Ese es el orden opuesto al "la memoria mata una sesión viva" de ③. −89dBm es demasiado débil para un asiento de cabina (normalmente −40 a −65dBm), y no hubo intento de reconexión → lo leemos como un apagado normal al aparcar.
El reporte "reinicios agrupados en 09:40-09:50" se confirmó en los logs. Tres eventos:
| # | Caída | Recuperación | Intervalo | Qué fue |
|---|---|---|---|---|
| 1 | 09:42:07 | 09:42:19 | 12s | renegociación de sesión, auto-recuperada |
| 2 | 09:47:28 | 09:47:31 | 2,2s | precedida por wificond: Failed to get Signal Strength (señal débil) → caída breve y recuperación |
| final | 09:49:59 | ninguna | — | el AP del coche cortó primero (locallyGenerated=false, rssi=-92) → cambió a Wi-Fi de casa = aparcado |
GhLifecycleService. Esos siempre quedarían si un recolector de memoria lo hubiera matado.Failed to get Signal Strength se repitió a intervalos de 10 segundos alrededor de las 09:47. Significa que la señal Wi-Fi del coche estuvo especialmente débil en ese tramo. No es un bug nuevo — solo las condiciones de RF de ese trayecto.El cuadro revisado: la causa nunca se fijó en una sola cosa — cambió de trayecto en trayecto. La autenticación Wi-Fi (①) se apagó para siempre eliminando la red guardada. La recolección por memoria (③) parecía probable el 7/13 pero no apareció en los dos trayectos siguientes. Las caídas realmente capturadas últimamente vinieron de señal débil (pérdida de baliza / fallo de lectura de señal), casi todas al aparcar. Así que las próximas soluciones deben mirar primero al RF.
Cada una se verificó de una en una — cambiar una sola cosa y luego conducir unos días vigilando la recurrencia.
Ajustes → Conexiones → Wi-Fi → ⋮ → Redes guardadas → <AP del coche> → Eliminar
WifiNetworkSpecifier) usando credenciales recibidas por Bluetooth, así que sigue funcionando tras eliminarla. Para revertir, basta con reconectar e introducir la contraseña.Desactivar Android Auto dentro de la Carpeta Segura (enabled=DISABLED_USER).
Subir desde Mantenimiento del dispositivo → Memoria → RAM Plus.
:projection seguía siendo recolectado bajo presión de memoria y ocurrían reinicios. La carga (load average) también quedó prácticamente igual antes y después del aumento (alivio de presión mínimo).Ajustes → Aplicaciones → Android Auto → Batería → "Sin restricciones"
Mantenimiento del dispositivo → quitar Android Auto, Google Play Services y la app de navegación de las listas de apps en suspensión / suspensión profunda
Qué hace realmente: esto bloquea la ruta de cierre forzado de Samsung vía suspensión de apps / Doze. Esa es una ruta aparte de la recolección por presión de memoria de lmkd que se diagnosticó, así que fijar una excepción de memoria no garantiza que se detengan las recolecciones del LMK. Aun así, es la solución más recomendada en línea para las desconexiones repetidas de AA inalámbrico y no tiene inconvenientes, por lo que vale la pena probarla primero. (Efecto aún no medido en este dispositivo.)
| Solución | Causa abordada | Efecto medido |
|---|---|---|
| A. Eliminar red guardada | ① · ② | Fallos de autenticación SAE 14/día → 0 (se mantuvo) |
| B. AA de Carpeta Segura off | ③ | thrashing de gearhead duplicado eliminado |
| C. RAM Plus 12 GB | ③ | limitado — no detuvo la recolección del helper, alivio mínimo. Revertir y comparar |
| D. Excepción de optimización de AA | (adyacente a ③) | no aplicado — bloquea la ruta suspensión/Doze (aparte de la ruta LMK). Siguiente candidato |
| Resultado acumulado | — | Fase 1 (autenticación Wi-Fi) eliminada (confirmado). Recolección por memoria (③) no reproducida el 7/14 y 7/29. Las caídas recientes fueron casi todas desvanecimiento de señal / aparcamiento (④) |
# 1) Comprobación de reinicio — ¿murió el teléfono de verdad?
adb shell uptime; adb shell getprop ro.boot.bootreason
# 2) Razón de salida de AA / importance — crash vs recolección por memoria
# (una recolección de :projection reason=3 dentro de la ventana de sesión es señal probable de colapso,
# pero nótese que también aparece en sesiones terminadas normalmente)
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
# 3) Eventos de conexión al AP del coche / razones de fallo — tormenta de reconexión / fallo de autenticación
adb shell dumpsys wifi | grep -i "<SSID-AP-coche>"
# 4) ¿Se auto-actualizó el perfil guardado a SAE?
adb shell dumpsys wifi | grep -iE "SAE|IsAddedByAutoUpgrade|RequirePmf"
# 5) Una vez, junto al coche — ¿el AP realmente anuncia WPA3 (SAE)? (confirma ①)
adb shell cmd wifi list-scan-results | grep -i "<SSID-AP-coche>"
# 6) Presión de memoria — memoria libre, swap, carga
adb shell cat /proc/meminfo | grep -E "MemFree|MemAvailable|SwapTotal|SwapFree"
adb shell uptime # load average
# 7) ¿Cayó por RF — pérdida de baliza / caída del lado del AP / fallo de lectura de señal (causa ④)
adb shell dumpsys wifi | grep -iE "determineBeaconLoss|NETWORK_DISCONNECTION|locallyGenerated"
# + rastrea límites de sesión con CDM isAppeared: false=caída, true=reanuda
adb logcat -b system -d | grep -iE "isAppeared|WirelessStartup|wirelessDisconnected"
# 8) Orden en el momento de la caída — deauth/pérdida-de-baliza vs kill del LMK, cuál va primero
adb logcat -b main -G 16M # ampliar el buffer antes de conducir (ojo al tope, ver abajo)
adb logcat -b main -d > drive.log # volcar justo después de conducir
[SAE] / [RSN-SAE] / [MFPR] → WPA3 anunciado, ① confirmado. Solo [WPA2-PSK-CCMP-128] → SAE descartado.rssi justo antes de la caída está por debajo de −85dBm o locallyGenerated=false, la causa ④ (RF / apagado al aparcar) es la lectura más probable.Para atrapar el código de razón de deauth / pérdida de baliza / los logs de kill del LMK en el momento de una caída, el buffer main de logcat es pequeño (unos pocos MiB por defecto, ~decenas de minutos) y se sobrescribe rápido. Amplíalo antes de la próxima conducción (n.º 8) y vuelca con -d justo después (no en streaming).
⚠️ Algunos dispositivos no agrandan el buffer. Este dispositivo (Samsung / Android 16) limita el buffer a 5 MiB aunque pases
-G 16M("MAX log buffer size is 5 MiB"). Bajo carga alta, 5 MiB siguen siendo solo unos minutos, así que es fácil perder la ventana del trayecto. Opciones: (a) volcar justo después del trayecto, o (b) dejar el teléfono conectado y registrar a un archivo en vivo durante todo el trayecto conadb logcat -b main,system -v time > drive.log. El 7/29 el buffer main ya se había sobrescrito; solo el buffersystem, que dura más, salvó la ventana → captura tambiénsystem.
Los logs/capturas extraídos del dispositivo contienen identificadores personales/de dispositivo (SSID/BSSID/dirección BT/cuentas). Enmascáralos antes de compartir/publicar.
| Ítem | Cómo se juzgó | Resultado en este caso |
|---|---|---|
| Crash de la app AA | exit-info reason=4/6 |
Ninguno (todas las salidas no-crash: LOW_MEMORY/FREEZER) |
| Reinicio del teléfono | uptime / bootreason |
Ninguno |
| Bucle de reconexión Wi-Fi (fase 1) | aumento de eventos de conexión en dumpsys wifi |
Confirmado → eliminado con la solución A (0, confirmado) |
| Fallo de autenticación WPA3/SAE | fallo en ASSOCIATING + status=1 |
Probable → eliminado (anuncio SAE del AP no confirmado). Aún 0 el 7/29 |
| Contención de red guardada | auto-actualización SAE del perfil guardado | Confirmado → resuelto con la solución A |
| Presión de memoria → recolección LMK | :projection reason=3 dentro de la ventana de sesión |
7/13 probable (no probado) → no reproducido el 7/14 y 7/29 |
| Señal Wi-Fi débil / pérdida de baliza (RF) | beaconLoss rssi, NETWORK_DISCONNECTION locallyGenerated=false, Failed to get Signal Strength |
Medido 7/14 y 7/29 — lo que fueron las caídas recientes (−89 a −92dBm). Casi todas apagado al aparcar, algunos flaps breves en marcha |
| Bug de GMS | versionName ≥ 26.22 |
Descartado (ya superado) |
Aviso de alcance: el análisis de cada trayecto explica solo los eventos cuyos límites de sesión quedaron en los logs. En este dispositivo ocupado el buffer se sobrescribe rápido, así que algunas caídas no se capturaron.