[edv-Shin]

목적

Maestro 채팅에서 B 준비 후 A를 실행할 때 반복되는 System UI ANR의 발생 구간과 호스트 자원 상태를 확인하기 위한 진단 PR입니다. ANR 해결이나 원인 확정을 주장하지 않습니다.

관련 PR: #636
실패 자료: https://github.com/projects200/android/actions/runs/39627405305/attempts/4
같은 현상이 관찰된 dev 실행: https://github.com/projects200/android/actions/runs/39056512651

dev의 3fe24f597d4d747cec4a2fe0cf0fbd8f81f938b1에서 별도 브랜치를 만들었습니다. #636의 타이머·DTO 변경은 포함하지 않습니다.

변경

• A의 네 지점에서 안전한 ANR 요약을 기록합니다: B 사용 가능 직후/A 재준비 전, A fixture 준비 직후, B ready 후/A 최초 실행 직전, 실패 후/fixture 정리 전.
• Android 14의 들여쓴 Reason:을 인식하고, am_anr 이벤트 최신 8건을 기기 시각·고정 프로세스/원인 분류로 남깁니다. 조회 실패·빈 결과·해석 불가·부분 수집을 구분합니다.
• B 생성/부팅 전부터 A 최초 open 결과까지 호스트 자원을 1초 간격으로 수집합니다. CPU busy/iowait·메모리/swap·load·지원되는 PSI의 숫자만 기록하며 표본 수와 출력 크기를 제한합니다. 이전 단계 실패·중단 시에도 fixture 정리 전에 중단합니다.
• 진단 실패가 기존 UI 실패나 계정별 fixture 복구를 덮지 않도록 하고, 관련 Python 동작 테스트와 기존 README를 갱신했습니다.

자료 위치는 기존 artifact 안의 chatting/diagnostics/<phase>/*.json, chatting/diagnostics/host-resources.log입니다. 현재 workflow의 JSON/log 업로드 경로를 그대로 사용합니다.

변경하지 않은 것과 해석 한계

• GPU·AVD·SDK·서명·재부팅·UI 대기시간·선택자·계정/fixture 격리·채팅 시나리오를 바꾸지 않았습니다. ANR 창 닫기나 재시도도 추가하지 않았습니다.
• 원본 logcat/dumpsys·예외 본문·URL·토큰·사용자 데이터·프로세스 인수/환경 변수는 새 진단에 저장하지 않습니다.
• ANR 이벤트는 기기 과거 이력이며 재부팅으로 지워질 수 있습니다. 캡처 시각은 ANR 발생 시각이 아니고 fixture-ready도 UI 건강 확인이 아닙니다.
• 주기 수집도 연속 관측은 아닙니다. 정상 표본이나 빈 기록만으로 순간 자원 경합을 배제할 수 없습니다. 기기/호스트 clock 차이와 진단 조회 자체의 부하도 고려해야 합니다.

검증

• 정적 검토: 변경 diff, Python 호출·실패·중단 경로, fixture 정리 계약, 기존 artifact 업로드 경로 확인.
• git diff --cached --check 통과(공백 검사만 해당).
• 이 봇의 실행 제한에 따라 로컬 Python 테스트·ktlint·APK 빌드·에뮬레이터·Maestro는 실행하지 않았습니다. Kotlin 변경은 없습니다.
• 확인 필요: 이 PR의 원격 CI에서 기존 Python unittest discovery 두 개, APK 빌드, 실제 authenticated Maestro 실행 결과와 새 진단 artifact를 확인해야 합니다. 기존 ANR가 재발해 전체 Maestro는 실패할 수 있습니다.