무선 Android Auto가 주행 중 반복적으로 "끊기고 다시 켜지는" 증상을 adb로 진단하는 절차와, 원인 후보·조치 후보를 정리한 문서다. 대부분의 경우 앱 크래시가 아니라 Wi-Fi 링크 드롭이며, 겉으로는 똑같이 "AA가 죽었다 살아난다"로 보인다. 실제 삼성 Galaxy(Android 16 / One UI 8.5) + Audi(Android Automotive 기반 MMI) 조합 사례를 일반화했다.
이 문서의 모든 명령은 읽기 전용(조회) 이다. 기기를 변경하지 않는다.
settings put,forget-network,pm clear등 변경 명령은 "조치" 섹션에서 별도로 다루며 사용자 판단으로 실행한다.
무선 AA 사용자가 "폰이 비정상 종료됐다가 재시작된다"고 느끼는 현상은 대개 셋 중 하나다. 어느 것인지부터 구분해야 엉뚱한 곳을 파지 않는다.
| 체감 증상 | 실제 정체 | 확인 방법 |
|---|---|---|
| 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) |
자바 예외로 크래시 | 진짜 앱 버그. 스택트레이스 확보 |
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회여야 한다. 한 번의 주행에서 연결 이벤트가 수십 번 찍히고, 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회 실행한다. 이 한 줄이 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 이상인데도 재발 → 배제됨)
증거 강도 순으로 후보를 나열한다. 하나로 단정하지 말고 위 진단으로 좁혀라.
① Android 16 WPA3/SAE 인증 회귀 (가장 유력)
실패가ASSOCIATING단계 +status=1. 같은 AP에 평소엔 붙음. 저장 프로파일이 SAE 자동승격. → Pixel/Galaxy의 Android 16 + WPA3-SAE AP 조합에서 "비번 맞는데 인증 실패"가 보고된 회귀와 시그니처 일치.
② 헤드유닛(AP) 측 세션/펌웨어 문제
status=1:UNSPECIFIED_FAILURE는 AP가 보낸 거부 코드다. 헤드유닛이 이전 세션 association을 못 치웠거나, 펌웨어가 오래됐을 수 있다. 차량 인포테인먼트 소프트웨어 업그레이드 후 끊김이 생긴 선례도 있다.
③ 블루투스 선(先)절단 → 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 프로세스 콜드 스타트/스왑-인이 느려진다. 끊김 자체를 만들지는 않지만 재시작을 느리게 만든다.
비파괴·가역·저비용 순. 개인 기기이므로 삭제/설정 변경은 스스로 판단해 실행한다. 하나 바꾸고 며칠 주행하며 재발 여부를 관찰하는 식으로 하나씩 검증하는 것을 권한다.
설정 → 연결 → 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 | 증폭 요인 |