Perfetto Trace Analyzer

Discover slices by name with flexible matching to quickly survey what's in a trace, then get aggregates and linkable examples without writing SQL. WHY USE THIS: - Explore unknown slice names and hot paths fast (no manual SQL). - See frequency and duration stats (min/avg/max and p50/p90/p99 when available) per slice name. - Get linkable examples (id, ts, dur, track_id) to jump in UI or correlate with other tools. - Filter by process, main thread, and time range to narrow investigations. PARAMETERS: - pattern: String to match against slice names. - match_mode: 'contains' (default), 'exact', or 'glob'. - process_name: Optional filter; supports '*' wildcard. - main_thread_only: Limit to process main threads. - time_range: {'start_ms': X, 'end_ms': Y}. - limit: Max example slices to return (default 100). OUTPUT: - aggregates: Per-slice-name counts and duration stats (min/avg/max, p50/p90/p99 when available). - examples: Top slices by duration with thread/process context and track id for linking. - notes: Capability or fallback notices.

Execute PerfettoSQL scripts (multi-statement) on trace data for advanced analysis. USE THIS WHEN: Other tools don't provide what you need, you need complex filtering/joins, or you want to correlate data across multiple tables. This is your power tool for custom analysis - use it when pre-built tools are too limiting. CAPABILITIES: Full SQL access to all trace tables including: - slice: All trace slices with timing - thread/process: Thread and process metadata - counter: Performance counters over time - android_anrs: ANR events - actual_frame_timeline_slice: Frame jank data - sched_slice: CPU scheduling information - android_binder_txns: Cross-process calls - heap_graph_*: Memory heap analysis SECURITY: Accepts full PerfettoSQL/SQLite scripts. No automatic LIMIT is applied; large queries may return many rows. The script is executed verbatim by TraceProcessor. COMMON PATTERNS: - Duration analysis: "SELECT name, dur/1e6 as ms FROM slice WHERE dur > 10e6" - Aggregation: "SELECT name, COUNT(*), AVG(dur)/1e6 FROM slice GROUP BY name" - Time filtering: "SELECT * FROM slice WHERE ts BETWEEN 1e9 AND 2e9" - Process filtering: "SELECT * FROM thread WHERE upid IN (SELECT upid FROM process WHERE name LIKE '%chrome%')" POWER USER TIP: Use `INCLUDE PERFETTO MODULE ...` statements to load standard library modules (supports wildcards like `android.*`). You can also use `CREATE PERFETTO TABLE`/ `VIEW`/`FUNCTION`/`MACRO`/`INDEX` where supported by TraceProcessor. References: - PerfettoSQL Syntax: https://perfetto.dev/docs/analysis/perfetto-sql-syntax - Standard Library (Prelude): https://perfetto.dev/docs/analysis/stdlib-docs#package-prelude

USE THIS WHEN: Investigating app freezes, unresponsiveness, "not responding" dialogs, or user complaints about app hangs. ANRs are critical issues where the main thread is blocked for >5 seconds, causing Android to consider killing the app. PROVIDES: Complete ANR list with severity assessment based on main thread state and system conditions. Each ANR includes garbage collection pressure analysis to identify memory-related causes. FILTERS: - process_name: Target app (supports wildcards: "com.example.*", "*browser*") - time_range: {'start_ms': X, 'end_ms': Y} to focus on specific periods ANR ANALYSIS CONTEXT: ANRs are critical performance issues that directly impact user experience. They typically occur due to: - Main thread blocking operations (I/O, network, database) - Lock contention and synchronization issues - Memory pressure causing excessive GC - Binder transaction delays - CPU-intensive operations on the main thread OUTPUT: - Timestamp and process information for each ANR - Main thread state (last known state at ANR ts) - GC event count near ANR (>10 events = memory pressure) - Severity heuristic: CRITICAL if GC>10; HIGH if main thread in sleep/IO wait or moderate GC; MEDIUM otherwise (system-critical processes escalate severity) NEXT STEPS: 1. Use anr_root_cause_analyzer with ANR timestamp for deep analysis 2. Check thread_contention_analyzer for lock-related causes 3. Run binder_transaction_profiler if ANR involves system services INTERPRETATION: Multiple ANRs in short time = systemic issue. Single ANR = investigate specific timestamp. No ANRs doesn't guarantee good performance - check jank metrics too. - Requires 'android.anrs' data source in the trace; otherwise returns ANR_DATA_UNAVAILABLE - Ensure the trace contains Android performance data - High ANR counts indicate systemic performance issues requiring investigation - Correlate ANR timestamps with other performance metrics (frame drops, memory pressure) - For detailed root cause analysis, use execute_sql_query() with ANR timestamps - Zero ANRs doesn't mean good performance - check trace coverage and data sources

Comprehensive root cause analysis for ANR events using multi-signal correlation. USE THIS WHEN: After detect_anrs finds an ANR, investigating a known freeze timestamp, or when users report specific times when the app became unresponsive. This tool looks at a ±10 second window around the issue to identify root causes. ANALYZES FOUR KEY SIGNALS: 1. Main thread blocking: Long non-running states (I/O wait, sleeping) preventing UI updates 2. Binder delays: Slow IPC calls to system services (>100ms transactions) 3. Memory pressure: Low available memory forcing excessive GC 4. Lock contention: Java synchronized blocks causing thread waits PARAMETERS: - process_name: Target process (required for some analyses) - anr_timestamp_ms OR time_range: The moment to investigate - analysis_window_ms: Context window size (default ±10 seconds) - deep_analysis: true for enhanced correlation insights - Validation: If both anr_timestamp_ms and time_range are provided, the timestamp must lie within the time_range or the tool returns INVALID_PARAMETERS OUTPUT INSIGHTS: - "likelyCauses": Ranked list of probable root causes - "rationale": Explanation of why each cause was identified - Detailed data for each signal type - Correlation notes when multiple causes interact STRENGTH: Unlike single-signal tools, this correlates multiple data sources to identify the true root cause. For example, it can distinguish between "ANR due to lock contention during GC" vs "ANR due to slow binder call" vs "ANR due to CPU starvation". TYPICAL FINDING: Most ANRs are caused by main thread lock contention or synchronous binder calls, not CPU overload. Requires binder and monitor_contention modules in the trace for those signals; missing modules are reported in 'notes'.

Profile CPU usage by thread to identify performance bottlenecks. USE THIS WHEN: Investigating high battery drain, thermal throttling, slow performance, or determining if your app is CPU-bound. Essential for understanding whether performance issues are due to excessive CPU usage or other factors (I/O, lock contention, etc.). SHOWS PER-THREAD: - CPU percentage of trace duration - Total runtime and scheduling counts - Average/max time slices (long slices = good, many short = thrashing) - CPUs used (indicates thread migration) - Optional: CPU frequency analysis if trace has DVFS data KEY METRICS: - Main thread >80% CPU: UI work needs offloading - Background thread >90%: Consider chunking work - Many threads with low %: Possible over-threading - High schedule count with low CPU%: Lock contention likely PROCESS PATTERNS: - process_name: Supports wildcards ("com.example.*") - group_by: Currently "thread" only - include_frequency_analysis: Adds CPU frequency correlation INTERPRETATION: High CPU doesn't always mean inefficient code - could indicate thermal throttling keeping CPU at low frequencies. Compare with cpu_frequency data. If CPU usage is low but performance is poor, investigate lock contention or I/O blocking instead. OUTPUT: Ranked thread list by CPU usage, with main thread flagged. Use this to identify which specific threads need optimization.

Reference guide for Perfetto trace analysis and MCP usage.

Official Perfetto documentation for getting started with trace analysis workflow and tools.