무선 Android Auto가 주행 중 반복적으로 "끊겼다 다시 켜지는" 증상의 실제 원인과, 직접 시도한 조치가 각각 어떤 효과를 냈는지 실측으로 정리한 문서다. 삼성 Galaxy(Android 16 / One UI 8.5) + Audi(Android Automotive 기반 MMI) 조합 사례.
핵심 — 원인은 하나로 굳지 않았다. 주행마다 다른 요인이 나타났다. ① 처음엔 Wi-Fi 링크 드롭(WPA3/SAE 인증 실패 폭풍)이 주 동인이었고, 저장된 차량 Wi-Fi를 삭제하자 인증 실패가 하루 14회 → 0회로 멎었다(데이터로 확정, 이후에도 유지). ② Wi-Fi가 잠잠해진 뒤 남은 재시작은 메모리 압박으로 OS의 LMK(Low Memory Killer)가 활성 AA 프로세스를 회수하는 것이 유력해 보였다(7/13). 하지만 그 뒤 두 번의 주행(7/14·7/29)에선 메모리 킬이 다시 나타나지 않았다. ③ 최근 실제로 잡힌 끊김은 대부분 Wi-Fi 전파가 약해서(비콘 상실 −89~−92dBm) 생긴 것이고, 그중 상당수는 그냥 주차하며 끊긴 정상 종료였다. → 그래서 다음 조치는 전파 쪽을 먼저 본다.
아래 "진단" 명령은 전부 읽기 전용(조회) 이다. 기기를 변경하지 않는다. 조치(저장망 삭제·설정 변경 등)는 별도 섹션이며 스스로 판단해 실행한다.
체감은 "폰이 죽었다 재시작"이지만 실제로는 둘 중 하나다. (a) 차량 5GHz 핫스팟 링크가 끊겨 AA 세션이 재시작되거나, (b) 메모리 압박으로 AA 프로세스가 회수돼 세션이 붕괴한다. 앱 크래시는 아니다 — gearhead(com.google.android.projection.gearhead) 종료 기록이 전 기간 비크래시 사유뿐이다(reason=3 LOW_MEMORY, 일부 reason=14 FREEZER; reason=4/5/6 = APP_CRASH/NATIVE_CRASH/ANR은 0건).
# 종료 사유·importance — 크래시(reason=4/6) vs 메모리 회수(reason=3) 판별
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
# 차량 AP 연결 이벤트 급증·인증 실패 여부
adb shell dumpsys wifi | grep -i "<차량AP_SSID>"
⚠️ 판별 기준 정정 (중요). "활성 세션은 importance
100/125(FOREGROUND)로 뜨므로,300(SERVICE)/400(CACHED) 종료는 전부 무해한 캐시 회수"라는 기준은 무선 AA에는 부정확하다. 무선 AA 세션은 알림·FGS를 쥔 main 프로세스만으로 돌지 않고,:projection·:car같은 **helper 프로세스(adj 300급)**가 함께 필요하다. 실측에서 메모리 압박 시 회수된 건 이 **helper들(imp 300/400)**뿐이고 main FGS(imp 125) 사망 기록은 없었다 — 그런데도 세션은 끊길 수 있다. 따라서 "100/125가 없으니 안전"이 아니라, 세션이 열린 시간창 안의 helper LOW_MEMORY 회수도 확인해야 한다. (helper가 왜 125가 아닌 300으로 찍히는지는 근거 미확보 — "관측상 300"으로만 본다.)
① Android 16 WPA3/SAE 인증 회귀 (1단계 주 동인 — 해소됨)
결정적 시그니처: 실패가AUTHENTICATION_FAILURE reason=3:WRONG_PSWD+supplicantStateChangeEvents:{ ASSOCIATING }+ASSOCIATION_REJECTION status=1. 비밀번호는 맞는데(전용 specifier 경로로는 부팅 후 134회 성공) association 이전 단계에서 실패한다. WPA2라면 비번은 association 이후 4-way handshake에서 검증되므로 이 단계에서 "비번 틀림"이 날 수 없다. SAE(WPA3)만 association 이전 Authentication 프레임에서 비번을 쓴다 → 실패 지점이 SAE 협상 실패와 정확히 일치. 저장 프로파일이KeyMgmt: SAE+IsAddedByAutoUpgrade: true(WPA2→WPA3 자동승격)였다.
주의(미확정): 저장망 삭제로 폭풍이 멎은 것은 "SAE 자동승격 저장 프로파일이 동인"임을 강하게 지지하지만 "AP가 WPA3"임을 증명하진 않는다. AP가 WPA2 전용이어도 저장 프로파일의 SAE 강제(KeyMgmt:SAE,RequirePmf:true)가 협상 불일치를 일으켜 같은 증상을 낼 수 있다. AP의 실제 SAE 광고 여부는 차량 옆 스캔 1회(진단 5번)로 최종 확인해야 한다.
② 저장망 경합 (①과 한 몸)
차량 AP가 일반 저장 네트워크로도 등록되어, 시스템 자동연결(저장망)과 AA 전용 연결(specifier)이 같은 AP를 두고 경합했다. SAE 자동승격은 바로 이 저장 프로파일에 붙어 있었다 → 저장망 삭제 한 번으로 ①·②가 동시에 사라진다.
③ 메모리 압박 → LMK가 활성 helper 회수 (7/13엔 유력, 이후 재현 안 됨)
Wi-Fi 인증 문제가 사라진 뒤 남은 재시작의 한때 유력 후보였다. 상주 대형 앱 다수로 여유 메모리가 1GB 미만까지 떨어지고 스왑을 상시 사용한다. 이 압력 아래 삼성 LMK가 SERVICE급(imp 300):projectionhelper를 회수하는 상관이 관측됐다:22:05 :projection reason=3 LOW_MEMORY 회수 → 22:09 세션 붕괴 → 22:12 재접속(3.5분 만의 끊김→재시작). RAM Plus는 스왑만 늘릴 뿐 adj-300 프로세스를 보호하지 않아 이를 막지 못했다.
한계(정직성): ⓐ 동일 시그니처(세션 창 내:projection300 회수)가 정상 종료된 세션에도 나타나 teardown 부수 현상과 구분이 안 된다. ⓑ 회수(22:05)와 붕괴(22:09) 사이 3.5분 갭 → 직접 사살이라기보다 다른 트리거 뒤 별개 회수였을 가능성 잔존. ⓒ main FGS 생존 여부 미확인. → 인과 "확정"이 아니라 "지지" 수준이었고, 아래 후속 관측에서 보듯 7/14·7/29 주행에선 이 시그니처가 재현되지 않았다.
④ Wi-Fi 전파 약화·비콘 상실 (RF — 최근 실측으로 승격)
인증 실패 흔적 없이 끊기는 경우다. 처음엔 "드문 잔존"으로만 봤지만, 7/14·7/29 주행 로그에서 최근 실제로 잡힌 끊김은 대부분 이 유형이었다. 신호:Conn.Personalizer determineBeaconLossDisconnection rssi=-89~-92(비콘 상실),NETWORK_DISCONNECTION_EVENT locallyGenerated=false(차량 AP가 먼저 끊음),wificond: Failed to get Signal Strength(신호 측정 실패). −89~−92dBm은 좌석에서 나올 수 없는 약한 값이라 주차·하차 정황과 맞는다. 주행 중 짧게 끊겼다 붙는 flap도 이 신호 약화와 같이 나타났다. AP측 절단(status=1)이나 BT↔Wi-Fi 핸드오프가 겹칠 수 있다. → 자세한 실측은 아래 후속 관측 절 참고.
③(메모리 회수)를 유력하게 본 뒤로 두 번 더 주행 로그를 잡았다. 그런데 메모리 킬 시그니처가 다시 나타나지 않았다. 대신 두 번 다 차량 Wi-Fi 전파가 약해서 끊긴 쪽에 가까웠다.
주행 종료 즈음 세션이 끊겼다. 로그의 순서가 중요하다: 프로젝션 화면이 먼저 정리되고 → 그다음 Wi-Fi가 끊겼다(beaconLoss rssi=-89). 메모리 회수는 맨 뒤에 일어났고, 이미 캐시(CACHED) 상태인 프로세스를 치우는 뒷정리였다. 즉 ③의 "메모리가 살아있는 세션을 죽인다"와 순서가 정반대다. −89dBm은 차 안 좌석에서 나올 수 없는 약한 값이고(보통 −40~−65dBm), 재접속 시도도 없었다 → 정상적인 주차 종료로 본다.
"09:40~09:50에 재시작이 몰렸다"는 신고를 로그로 확인했다. 세 건으로 확정된다.
| 순서 | 끊김 | 복구 | 간격 | 정체 |
|---|---|---|---|---|
| 1 | 09:42:07 | 09:42:19 | 12초 | 세션 재협상, 스스로 복구 |
| 2 | 09:47:28 | 09:47:31 | 2.2초 | 직전에 wificond: Failed to get Signal Strength(전파 약화) → 짧게 끊겼다 복구 |
| 최종 | 09:49:59 | 없음 | — | 차량 AP가 먼저 끊음(locallyGenerated=false, rssi=-92) → 집 Wi-Fi로 전환 = 주차 완료 |
GhLifecycleService 재시작 로그가 하나도 없다. 메모리 회수로 죽었다면 반드시 남을 로그다.Failed to get Signal Strength가 09:47대에 10초 간격으로 반복됐다. 이 구간에서 차량 Wi-Fi 전파가 유독 약했다는 뜻이다. 새 버그가 아니라 이날 주행의 전파 여건 문제로 설명된다.바뀐 그림: 원인은 하나로 굳은 게 아니라 주행마다 달랐다. Wi-Fi 인증(①)은 저장망 삭제로 확실히 껐다. 메모리 회수(③)는 7/13엔 유력했지만 그 뒤 두 번의 주행에선 안 나타났다. 최근 실제로 잡힌 끊김은 전파가 약해서(비콘 상실·신호 측정 실패) 생겼고, 대부분 주차 종료였다. 그러니 다음 조치는 전파 쪽을 먼저 본다.
한 번에 하나만 바꾸고 며칠 주행하며 재발을 관찰해 하나씩 검증했다.
설정 → 연결 → Wi-Fi → ⋮ → 저장된 네트워크 → <차량 AP> → 삭제
WifiNetworkSpecifier)를 써서 직접 붙으므로 삭제 후에도 정상 동작한다. 되돌리려면 다시 접속해 비번을 넣으면 된다.보안폴더 안의 Android Auto를 비활성화(enabled=DISABLED_USER).
디바이스 케어 → 메모리 → RAM Plus 상향.
:projection이 회수돼 재시작이 발생했다. 증설 전후로 부하(load average)도 거의 불변이었다(압박 완화 미미).설정 → 앱 → Android Auto → 배터리 → "제한 없음(Unrestricted)"
디바이스 케어 → 절전(잠자는 앱)·딥 슬립 앱 목록에서 Android Auto·Google Play Services·내비 앱 제외
성격 정리: 이 조치는 삼성 앱 재우기/Doze에 의한 강제 종료 경로를 막는다. 이는 진단된 lmkd 메모리 압박 회수와는 별개 경로이므로, 메모리 예외 지정만으로 LMK 회수가 막힌다는 보장은 없다. 그래도 온라인에서 무선 AA 반복 끊김에 가장 널리 권장되는 조치이고 부작용이 없어 우선 시도 가치가 있다. (효과는 본 기기 미실측)
| 조치 | 대응 원인 | 실측 효과 |
|---|---|---|
| A. 저장망 삭제 | ① · ② | SAE 인증 실패 14회/일 → 0회 (유지) |
| B. 보안폴더 AA off | ③ | 중복 gearhead thrashing 소거 |
| C. RAM Plus 12GB | ③ | 제한적 — helper 회수 못 막음, 부하 완화 미미. 원복 비교 권장 |
| D. AA 최적화 예외 | (③ 인접 경로) | 미적용 — 앱 재우기/Doze 경로 차단(LMK 경로와는 별개). 다음 시도 후보 |
| 누적 결과 | — | 1단계(Wi-Fi 인증) 소멸(확정). 메모리 회수(③)는 7/14·7/29 재현 안 됨. 최근 끊김은 대부분 전파 약화·주차 종료(④) |
# 1) 재부팅 여부 — 폰이 실제로 죽었는지
adb shell uptime; adb shell getprop ro.boot.bootreason
# 2) AA 종료 사유·importance — 크래시 vs 메모리 회수 판별
# (세션 시간창 안의 :projection reason=3 회수 = 세션 붕괴 유력 신호, 단 정상 종료에도 나타남에 주의)
adb shell dumpsys activity exit-info com.google.android.projection.gearhead
# 3) 차량 AP 연결 이벤트·실패 사유 — 재연결 폭풍/인증 실패 확인
adb shell dumpsys wifi | grep -i "<차량AP_SSID>"
# 4) 저장 프로파일이 SAE 자동승격됐는지
adb shell dumpsys wifi | grep -iE "SAE|IsAddedByAutoUpgrade|RequirePmf"
# 5) 차량 옆에서 1회 — AP가 실제 WPA3(SAE)를 광고하나 (원인 ① 확정)
adb shell cmd wifi list-scan-results | grep -i "<차량AP_SSID>"
# 6) 메모리 압박 실측 — 여유 메모리·스왑·부하
adb shell cat /proc/meminfo | grep -E "MemFree|MemAvailable|SwapTotal|SwapFree"
adb shell uptime # load average
# 7) 전파로 끊겼는지 — 비콘 상실·AP측 절단·신호 측정 실패 (원인 ④)
adb shell dumpsys wifi | grep -iE "determineBeaconLoss|NETWORK_DISCONNECTION|locallyGenerated"
# + 세션 경계는 CDM isAppeared 로 추적: false=끊김, true=재개
adb logcat -b system -d | grep -iE "isAppeared|WirelessStartup|wirelessDisconnected"
# 8) 끊김 순간 선후 확정 — deauth/비콘상실 vs LMK 킬 중 무엇이 먼저인지
adb logcat -b main -G 16M # 주행 전 버퍼 확대(상한 주의, 아래 팁)
adb logcat -b main -d > drive.log # 주행 직후 덤프
[SAE] / [RSN-SAE] / [MFPR] → WPA3 광고, 원인 ① 확정. [WPA2-PSK-CCMP-128]만 → SAE 기각.rssi가 −85dBm보다 낮거나 locallyGenerated=false면 원인 ④(전파/주차 종료)에 무게가 실린다.끊김 순간의 deauth 사유 코드·비콘 상실·LMK 킬 로그를 잡으려면, main logcat 버퍼가 작아(기본 수 MiB, 십수 분치) 금방 덮인다. 다음 주행 전에 키워 둔다(진단 8번). 주행 직후 -d로 덤프(스트리밍 아님)한다.
⚠️ 버퍼가 안 커지는 기기가 있다. 이 기기(삼성 / Android 16)는
-G 16M을 넣어도 상한이 5 MiB로 고정돼 그 이상 안 커진다("MAX log buffer size is 5 MiB"). 부하가 높으면 5 MiB도 몇 분치라 주행 구간을 놓치기 쉽다. 대안: (a) 주행 직후 바로 덤프하거나, (b) 폰을 연결해 두고adb logcat -b main,system -v time > drive.log로 주행 내내 파일에 실시간 기록한다. 참고로 7/29엔 main 버퍼가 이미 덮였고, 더 오래 남은system버퍼 덕에 겨우 구간을 건졌다 →system버퍼도 같이 확보하는 걸 권한다.
기기에서 뽑은 로그·스크린샷에는 SSID/BSSID/BT 주소/계정 등 개인·디바이스 식별 정보가 담긴다. 공유·게시 전 마스킹할 것.
| 항목 | 판정 방법 | 이 사례 결과 |
|---|---|---|
| AA 앱 크래시 | exit-info reason=4/6 |
없음 (종료 사유 전부 비크래시: LOW_MEMORY/FREEZER) |
| 폰 재부팅 | uptime / bootreason |
없음 |
| Wi-Fi 재연결 루프 (1단계) | dumpsys wifi 연결 이벤트 급증 |
확인됨 → 조치 A로 소멸(0회, 확정) |
| WPA3/SAE 인증 실패 | 실패 지점 ASSOCIATING + status=1 |
유력 → 소멸 (AP SAE 광고는 미확정). 7/29에도 0건 유지 |
| 저장망 경합 | 저장 프로파일 SAE 자동승격 | 확인 → 조치 A로 해소 |
| 메모리 압박 → LMK 회수 | 세션 창 내 :projection reason=3 |
7/13 유력(인과 미확정) → 7/14·7/29 재현 안 됨 |
| Wi-Fi 전파 약화·비콘 상실 (RF) | beaconLoss rssi, NETWORK_DISCONNECTION locallyGenerated=false, Failed to get Signal Strength |
7/14·7/29 실측 — 최근 끊김의 정체(−89~−92dBm). 대부분 주차 종료, 일부 주행 중 짧은 flap |
| GMS 버그 | versionName ≥ 26.22 |
배제(이미 상회) |
범위 주의: 각 주행의 분석은 로그로 세션 경계가 남은 건만 설명한다. 부하 높은 기기라 버퍼가 금방 덮여, 캡처 못 한 끊김도 있다.