Este documento describe el procedimiento para diagnosticar con adb el síntoma de que Android Auto inalámbrico se "desconecta y se vuelve a encender" repetidamente durante la conducción, junto con una lista de causas candidatas y acciones candidatas. En la mayoría de los casos no se trata de un fallo de la aplicación, sino de una caída del enlace Wi-Fi, aunque desde fuera se percibe igual: "AA se muere y revive". Se ha generalizado a partir de un caso real con la combinación de un Samsung Galaxy (Android 16 / One UI 8.5) y un Audi (MMI basado en Android Automotive).
Todos los comandos de este documento son de solo lectura (consulta). No modifican el dispositivo. Los comandos que sí modifican, como
settings put,forget-networkopm clear, se tratan por separado en la sección "Acciones" y se ejecutan según el criterio del usuario.
El fenómeno que los usuarios de AA inalámbrico perciben como "el teléfono se cierra de forma anómala y se reinicia" suele ser una de tres cosas. Hay que distinguir primero de cuál se trata para no investigar en el lugar equivocado.
| Síntoma percibido | Naturaleza real | Método de verificación |
|---|---|---|
| La pantalla de AA se apaga y vuelve a aparecer | Caída del enlace Wi-Fi → reinicio de la sesión de AA (lo más frecuente) | Aumento brusco de eventos de conexión Wi-Fi |
| Solo la aplicación de AA se cierra | Fallo de la aplicación (reason=4) o ANR (reason=6) | Registro de crash en exit-info |
| El teléfono entero se reinicia | Kernel panic / watchdog | uptime, bootreason |
Primero se comprueba si el teléfono se ha reiniciado realmente.
adb shell uptime
adb shell getprop ro.boot.bootreason
Si uptime se mantiene en el orden de días y bootreason es shutdown,userrequested (apagado normal), entonces el teléfono no se ha reiniciado nunca. En ese caso el problema se reduce al nivel de aplicación o al nivel de enlace.
exit-infoEl ApplicationExitInfo de Android 11+ deja registrado el motivo por el que murió un proceso. El paquete de AA es com.google.android.projection.gearhead.
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
Se examina el reason de cada registro.
| reason | Significado | Interpretación |
|---|---|---|
4 (APP CRASH) |
Crash por excepción de Java | Bug real de la aplicación. Conseguir la traza de pila |
6 (ANR) |
Sin respuesta | La aplicación se cuelga |
3 (LOW_MEMORY) |
Recuperación de memoria | No es un crash. Limpieza de caché |
5 (NATIVE CRASH) |
Crash nativo | Revisar el tombstone |
En el caso real, los registros de terminación de AA eran todos
reason=3 (LOW_MEMORY), y en el momento de morir todos los procesos estaban en estado de caché/servicio (importance 300~400). Es decir, no murió durante una sesión activa de AA, sino que se recuperó un proceso que ya había pasado a caché tras terminar la sesión. En este caso la causa no es la aplicación de AA.
También se examina el valor importance. Si murió en 100 (FOREGROUND) / 125 (FOREGROUND_SERVICE), fue la muerte de una sesión activa, pero si fue en 300 (SERVICE) / 400 (CACHED), ya había pasado a segundo plano antes de ser eliminado.
Si no es un crash, se examina el enlace Wi-Fi. AA inalámbrico funciona con el teléfono conectado al punto de acceso de 5 GHz que levanta el vehículo para intercambiar datos, así que si ese enlace se corta, la sesión de AA también se corta.
# Historial de eventos de conexión con el AP del coche (incluye éxito/fallo y motivo del fallo)
adb shell dumpsys wifi | grep -i "<AP_coche_SSID>"
# Cronología de transiciones de estado del supplicant (comprobar repetición associating↔disconnected)
adb shell dumpsys batterystats --history | grep -iE "wifi_suppl|<AP_coche_SSID>"
Si todo es normal, debería haber una conexión por trayecto. Si en un solo trayecto se registran decenas de eventos de conexión y el supplicant repite associating ↔ disconnected cada pocos segundos, ha caído en un bucle de reconexión.
En los eventos de fallo de conexión de dumpsys wifi, el punto donde se produce el fallo es la pista clave.
AUTHENTICATION_FAILURE_EVENT reason=3:ERROR_AUTH_FAILURE_WRONG_PSWD
supplicantStateChangeEvents: { ASSOCIATING }
ASSOCIATION_REJECTION_EVENT status=1:UNSPECIFIED_FAILURE
Esta combinación apunta a un caso peculiar en el que la contraseña es correcta pero la autenticación falla. Puntos de identificación:
WRONG_PSWD pero normalmente sí se conecta bien a la misma red → la contraseña es correcta; "wrong password" es un falso positivo.ASSOCIATING (antes de completar la association). En WPA2 la contraseña se verifica en el 4-way handshake posterior a la association, así que en esta fase no puede aparecer un "contraseña incorrecta". En WPA3 (SAE) la contraseña se usa en la trama de Authentication anterior a la association → este punto de fallo coincide exactamente con un fallo de negociación SAE.Comprobar si el perfil de red guardado se trata como WPA3:
adb shell dumpsys wifi | grep -iE "SAE|IsAddedByAutoUpgrade|RequirePmf"
Si aparecen KeyMgmt: SAE + IsAddedByAutoUpgrade: true, significa que Android ha promocionado automáticamente a WPA3 un perfil que originalmente era WPA2. Se sospecha que esta promoción automática se rompe en la negociación SAE con algunas unidades de cabecera (head units).
Se ejecuta una vez cerca del vehículo. Esta única línea confirma o descarta la hipótesis SAE.
adb shell cmd wifi list-scan-results | grep -i "<AP_coche_SSID>"
[SAE] / [RSN-SAE] / [MFPR] → anuncia WPA3. Hipótesis SAE confirmada.[WPA2-PSK-CCMP-128][RSN-PSK-CCMP-128][ESS] → solo WPA2. Hipótesis SAE descartada; pasar a otro candidato.El 2026-06-08, Google Play Services 26.22 incluyó una "corrección de un bug relacionado con Device Connection", y se difundió ampliamente como solución para las desconexiones de AA inalámbrico. Primero se comprueba si este teléfono ya lo tiene aplicado.
adb shell dumpsys package com.google.android.gms | grep versionName
Si la versión es 26.22 o superior y aun así el síntoma persiste, ese famoso bug no es la causa. (Caso real: reaparece incluso con 26.24 o superior → descartado)
Se enumeran los candidatos por orden de solidez de la evidencia. No des ninguno por sentado; acótalo con el diagnóstico anterior.
① Regresión de autenticación WPA3/SAE en Android 16 (la más probable)
El fallo está en la faseASSOCIATING+status=1. Normalmente sí se conecta al mismo AP. El perfil guardado tiene promoción automática a SAE. → La firma coincide con la regresión reportada de "contraseña correcta pero autenticación fallida" en la combinación de Android 16 + AP WPA3-SAE en Pixel/Galaxy.
② Problema de sesión/firmware en el lado de la unidad de cabecera (AP)
status=1:UNSPECIFIED_FAILUREes el código de rechazo enviado por el AP. Puede que la unidad de cabecera no haya liberado la association de la sesión anterior, o que el firmware esté anticuado. También hay precedentes de desconexiones que aparecieron tras actualizar el software del infotainment del vehículo.
③ Corte previo de Bluetooth → corte de Wi-Fi
AA inalámbrico es una combinación de BT (emparejamiento·audio) + Wi-Fi (datos). Si se desconecta con buena señal (-30~-40 dBm), puede no ser un problema de distancia RF, sino un problema de la pila BT. Hay numerosos reportes relacionados con el reciente BT 5.4 / LE Audio.
④ Competencia entre redes guardadas / "evitar el Wi-Fi malo"
Si el AP del coche también queda registrado como una red guardada normal, la conexión automática del sistema y la conexión exclusiva de AA compiten por el mismo AP. Connetwork_avoid_bad_wifi=1, el sistema tiende a evitar el AP del coche que no tiene internet.
⑤ Presión de memoria (factor amplificador, no la causa)
Con RAM Plus (memoria virtual), en lugar de matar las aplicaciones se empujan a zram, con lo que, al recuperarse el enlace, el arranque en frío / swap-in del proceso de AA se vuelve más lento. No provoca la desconexión en sí, pero hace más lento el reinicio.
En orden de no destructivo · reversible · bajo coste. Como es un dispositivo personal, las eliminaciones/cambios de configuración se ejecutan según tu propio criterio. Se recomienda validarlas de una en una: cambiar una cosa y conducir unos días observando si el problema reaparece.
Ajustes → Conexiones → Wi-Fi → ⋮ → Redes guardadas → <AP del coche> → Eliminar
WifiNetworkSpecifier) usando las credenciales recibidas por Bluetooth, así que AA inalámbrico sigue funcionando con normalidad. Para revertirlo, basta con volver a conectarse e introducir la contraseña.Si se confirma la causa ①, la solución alternativa conocida y definitiva es bajar el AP a solo WPA2. Comprueba con el manual/concesionario si el MMI del vehículo expone el ajuste de seguridad Wi-Fi.
Si la build del infotainment del vehículo está anticuada (comprobar por la fecha del parche de seguridad), actualízala. Portal de actualizaciones del fabricante o concesionario.
Opciones de desarrollador → Bluetooth LE Audio Mode → Disable y reiniciar. (Como medida adicional, también hay casos con A2DP hardware offload en OFF)
Para capturar incluso el código de motivo del deauth en el instante de la desconexión, hay que tener en cuenta que el búfer del logcat main es pequeño (por defecto unos pocos MiB, algo más de diez minutos) y se sobrescribe enseguida. Amplíalo antes del siguiente trayecto.
adb logcat -b main -G 16M # Ampliar el búfer
# ... conducir y reproducir el síntoma ...
adb logcat -b main -d > drive.log # Volcado justo después de conducir (no streaming)
Los logs y capturas de pantalla extraídos del dispositivo contienen información de identificación personal y del dispositivo, como SSID/BSSID/dirección BT/cuenta. Enmascárala antes de compartir o publicar.
| Elemento | Método de veredicto | Resultado de este caso |
|---|---|---|
| Crash de la aplicación de AA | exit-info reason=4/6 |
Ninguno (todo LOW_MEMORY) |
| Reinicio del teléfono | uptime / bootreason |
Ninguno |
| Bucle de reconexión Wi-Fi | Aumento brusco de eventos de conexión en dumpsys wifi |
Confirmado |
| Fallo de autenticación WPA3/SAE | Punto de fallo ASSOCIATING + status=1 |
Probable |
| Bug de GMS | versionName ≥ 26.22 |
Descartado (ya al día) |
| Presión de memoria | zram/loadavg | Factor amplificador |