AOSP: Extracting Logs with adb bugreport
How adb bugreport works internally in AOSP, what it collects, and how to pull out specific logs from the zip.
August 6, 2026
AOSP: Extracting Logs with adb bugreport
adb bugreport는 디바이스의 상태를 한 번에 스냅샷으로 뜨는 가장 기본적인 디버깅 명령어입니다.logcat, dmesg, dumpsys, ANR trace, tombstone 등을 개별적으로 따로 뽑을 필요 없이, 이 커맨드 하나로 대부분의 정보를 한 번에 수집할 수 있습니다.Basic usagesh
Under the Hood
adb bugreport는 사실 새로운 로직을 직접 수행하지 않고, 디바이스 안의 dumpstate 바이너리를 트리거하는 래퍼입니다.API 24 이상에서는 zipped bugreport 방식을 사용하는데, 그 흐름은 대략 이렇습니다.
What adb actually triggers on-devicesh
bugreportz가 PROGRESS: 라인을 계속 흘려주면 adb가 이를 받아 진행률을 표시하고, OK:가 나오면 해당 경로의 파일을 adb pull로 호스트에 가져온 뒤 디바이스 쪽 임시 파일을 정리합니다.실제 로그 수집은 전부 디바이스 안에서
dumpstate가 처리합니다.What's Inside the Zip
압축을 풀어보면 생각보다 다양한 파일들이 들어있습니다.
| 경로 | 내용 |
|---|---|
bugreport-*.txt | 메인 텍스트 리포트. dumpstate의 모든 출력이 여기 한 파일에 순서대로 쌓입니다 |
main_entry.txt | zip 안에서 메인 텍스트 파일이 무엇인지 가리키는 포인터 |
version.txt | bugreport 포맷 버전 |
FS/data/anr/traces.txt | ANR 발생 시점의 전체 스레드 덤프 |
FS/data/tombstones/ | 네이티브 크래시 tombstone 파일들 |
proto/*.proto | dumpsys --proto로 수집된 바이너리 서비스 상태 (activity, meminfo 등) |
screenshot.png | 리포트 생성 시점의 화면 캡처 (지원 기기에 한함) |
결국 핵심은
bugreport-*.txt 하나이고, 나머지는 이미 텍스트 리포트 안에 요약/포함된 내용을 원본 그대로 다시 첨부해둔 것에 가깝습니다.Commands Dumpstate Runs Internally
bugreport-*.txt를 열어보면 각 섹션이 ------ 섹션 이름 (실행된 커맨드) ------ 형태의 헤더로 구분되어 있습니다.즉 어떤 커맨드로 그 데이터를 뽑았는지가 리포트 자체에 그대로 남아있습니다.
Section headers found inside bugreport-*.txtsh
마지막
바쁜 디바이스에서 뽑은 bugreport가 수십 MB씩 나오는 이유도 대부분 이
DUMPSYS 섹션이 실제로는 가장 방대한데, 그 안에서 다시 activity, meminfo, batterystats, package, window 등 등록된 시스템 서비스마다 dumpsys <service>가 하나씩 반복 실행된 결과가 이어집니다.바쁜 디바이스에서 뽑은 bugreport가 수십 MB씩 나오는 이유도 대부분 이
DUMPSYS 섹션 때문입니다.벤더 보드마다 로그가 추가로 붙기도 하는데, 이건
dumpstate가 IDumpstateDevice 벤더 HAL을 호출해서 모뎀/Wi-Fi 펌웨어 로그 같은 보드 종속적인 정보를 이어 붙이기 때문입니다.Result
adb bugreport 하나로 logcat + dmesg + ANR trace + tombstone + dumpsys 스냅샷을 한 번에 확보할 수 있고, 각 데이터가 어떤 커맨드에서 나왔는지도 리포트 안 섹션 헤더로 그대로 확인할 수 있습니다.버그 재현 후 상태를 남겨야 할 때, 여러 명령어를 따로 뽑기보다는 이 한 줄로 충분한 경우가 많습니다.