Android Log Analysis
Overview
对 Android 设备导出的各类日志（bugreport、logcat、dropbox、tombstone、dmesg、anr traces）进行系统化检索与根因分析，产出结构化的 Markdown 分析报告：问题结论 → 根因分析 → 证据日志 → 修复建议。
本 skill 不依赖 adb 设备连接，只处理本地日志文件。大日志文件必须用 Grep 工具按模式检索关键片段，禁止一次性读入全文。
工作流程
第 1 步：识别输入文件类型
对用户提供的文件/目录，先判断类型（可看文件头几行、文件名、目录结构）：
| 输入 | 识别特征 | 主要覆盖问题 |
|---|---|---|
| bugreport | 文件开头有 == dumpstate 或包含多个 section（如 ------ SYSTEM LOG、------ CPU INFO） |
全部场景，信息最全 |
| logcat 文本 | 行格式 MM-DD HH:MM:SS.mmm PID TID LEVEL TAG: msg |
崩溃、闪退、卡顿 |
| dropbox 目录 | 文件名如 system_app_crash@<时间>、system_server_watchdog@、system_server_anr@、system_app_anr@、system_server_wtf@、SYSTEM_RESTART@ |
崩溃、ANR、WatchDog、SystemServer 重启 |
| tombstone (X00) | 文件头 *** *** *** + Build fingerprint + signal X (SIG...) |
Native 崩溃 |
| anr traces | 文件头包含 ----- pid <pid> at <time> -----，含各线程 Cmd line: 和堆栈 |
ANR、卡顿、死锁 |
| dmesg / kernel log | 行带 [ 123.456789] 时间戳 |
重启原因、黑屏、死机、硬件问题 |
| event log | tag 如 am_crash、am_anr、am_proc_died、boot_progress_start |
快速定位崩溃/ANR 事件与时间点 |
判断不了就问用户，或先 Grep 上述特征。多个文件时先建立时间轴（各文件的日志时间范围），再决定分析顺序。
第 2 步：按问题场景检索关键日志
先问清（或从上下文推断）：问题现象（崩溃/ANR/黑屏/重启/卡顿）、发生的大致时间、涉及的包名。然后按场景用 Grep 检索。详细模式与解读方法见 references：
- 应用崩溃 / 闪退（Java + Native） → 读
references/crash-analysis.md - ANR → 读
references/anr-analysis.md - WatchDog、黑屏、重启原因、卡顿、死机 → 读
references/system-issues.md
快速入口（任何场景都先跑一遍，锁定事件时间点）：
Grep pattern: "FATAL EXCEPTION|Force finishing activity|am_crash|Process .* has died|beginning of crash"
Grep pattern: "ANR in|am_anr|Input dispatching timed out"
Grep pattern: "WATCHDOG|Watchdog:|WATCHDOG_KILL|Boot animation"
Grep pattern: "Kernel panic|reboot,|SysRq|watchdog! |Power key|pm_sleep|charger"
Grep pattern: "am_anr|am_crash|am_proc_died|am_wtf|boot_progress"
检索命中后：用行号附近的上下文（Grep 的 -A/-B/-C）还原现场，再回到完整日志核对因果顺序（谁先谁后、是否同一 PID/时间戳）。
第 3 步：根因分析与交叉验证
- 时间轴对齐：把崩溃/ANR/重启等事件按时间排序，确认因果链（例：binder 耗尽 → SystemServer watchdog → 软重启）。
- 区分直接原因与根因：崩溃堆栈的异常类型是直接原因；要往上追是谁传入了坏数据、哪个系统服务未响应。
- 多源印证：Java crash 看 logcat + dropbox 双份；Native crash 看 tombstone + logcat 的
Fatal signal；ANR 看 event logam_anr+ traces 主线程堆栈；重启看 dmesg +SysRq/reboot reason。 - 排除噪声：忽略与本问题无关的高频日志（如 DEBUG 重复输出）；注意日志轮转导致的关键行丢失，此时明确告知证据不完整。
第 4 步：输出 Markdown 分析报告
报告写入文件（默认 <工作目录>/log-analysis-report.md），结构固定：
# Android 日志分析报告
- 分析对象：<文件清单及各自时间范围>
- 问题现象：<一句话>
## 结论（TL;DR）
<1-3 句：问题类型、直接原因、根因、置信度>
## 时间轴
| 时间 | 事件 | 证据来源 |
|------|------|----------|
## 根因分析
<分因果链展开，每条结论都附日志原文片段（含文件与行号）>
## 证据日志
<关键日志原文，标注文件:行号>
## 修复建议
<按优先级排列，区分 应用侧 / 系统侧 / 硬件侧>
## 未能确认的疑点
<证据不足的地方，说明还需要什么日志>
对话中给出 TL;DR 与报告路径，用 present_files 展示报告。
关键原则
- 大文件（>1MB）一律先 Grep 定位再局部 Read，禁止全量读入。
- 每条结论必须有日志证据支撑；证据不足时如实标注"推测"并说明缺什么。
- 遇到第三方厂商定制 ROM（日志 tag 不同），先从 bugreport 的 dumpstate 头部确认设备与版本，再调整检索模式。
- 涉及敏感信息（用户数据、账号）的日志片段在报告中脱敏。
