Android Performance Observability
CommunitykrutikJain
Measure startup, rendering, memory, jank, vitals, logs, and crash signals for Android apps with actionable traces.
Overview
- Repository
- krutikJain/android-agent-skills
- Publisher
- krutikJain
- Stars
- 14
- Forks
- 5
- Bundled files
- 5
- License
- MIT
- Updated
- Mar 25, 2026
Installation
tmp=$(mktemp -d)
git clone --depth 1 https://github.com/krutikJain/android-agent-skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/android-performance-observability" ~/.claude/skills/android-performance-observability
rm -rf "$tmp"tmp=$(mktemp -d)
git clone --depth 1 https://github.com/krutikJain/android-agent-skills.git "$tmp"
mkdir -p ~/.codex/skills
cp -R "$tmp/skills/android-performance-observability" ~/.codex/skills/android-performance-observability
rm -rf "$tmp"Install the Android Performance Observability agent skill from https://github.com/krutikJain/android-agent-skills/tree/main/skills/android-performance-observability into this project's skills folder.Instructions
Android Performance Observability
When To Use
- Use this skill when the request is about: android performance profiling, baseline profile or macrobenchmark, app startup issue android.
- Primary outcome: Measure startup, rendering, memory, jank, vitals, logs, and crash signals for Android apps with actionable traces.
- Read
references/patterns.mdwhen you need the measurement ladder for startup, jank, traces, and production signals. - Read
references/scenarios.mdfor repeatable profiling and trace-oriented entry points. - Handoff skills when the scope expands:
android-compose-performanceandroid-ci-cd-release-playstore
Workflow
- Classify the symptom before choosing tools: cold start, warm start, frame/jank, scrolling, memory, ANR, crash, battery, or production vitals drift.
- Measure on release-like builds and physical devices whenever possible; avoid debugging from debug-only traces or profile-unfriendly builds.
- Pick the smallest tool that answers the question: Macrobenchmark for startup/scroll numbers, Baseline Profiles for ahead-of-time optimization, Perfetto/System Tracing for deep traces, JankStats or FrameMetrics for frame quality, and Play Vitals for field evidence.
- Change one thing at a time, then compare before and after traces or benchmark outputs instead of stacking multiple optimizations blindly.
- Hand off UI-specific rendering changes or release rollouts only after the measurement surface is stable and the bottleneck is evidenced.
Guardrails
- Treat benchmarks, traces, and vitals as different evidence sources with different noise profiles; do not mix them casually.
- Prefer reproducible release-build measurements over debug-build intuition.
- Tie optimizations back to user-facing metrics such as startup time, frame pacing, ANRs, or battery impact.
- Keep the profiling setup stable enough that regressions are attributable to code changes instead of device or environment churn.
Anti-Patterns
- Chasing micro-optimizations before identifying whether the problem is startup, rendering, I/O, or field reliability.
- Reading one noisy trace and presenting the result as settled fact.
- Measuring debug builds and assuming the same behavior in production.
- Adding Baseline Profiles or macrobenchmarks without checking whether the target path is stable enough to compare.
Review Focus
- Startup: cold and warm launch, expensive initialization, and Baseline Profile coverage.
- Rendering: jank, skipped frames, Compose or View invalidation churn, and long main-thread work.
- Memory and reliability: allocations, leaks, ANRs, crashes, and Play Vitals trends.
- Evidence quality: repeatable commands, release-like variants, and documented before/after comparisons.
Examples
Happy path
- Scenario: Audit the repo for profiling surfaces and benchmark-related hooks before proposing a measurement plan.
- Command:
rg -n "baseline|macrobenchmark|profileable|JankStats|Trace|Perfetto" .
Edge case
- Scenario: Keep startup and rendering investigations grounded in repeatable release-like builds.
- Command:
cd examples/orbittasks-compose && ./gradlew :app:assembleDebug
Failure recovery
- Scenario: Keep observability requests distinct from Compose-only tuning or release automation.
- Command:
python3 scripts/eval_triggers.py --skill android-performance-observability
Done Checklist
- The bottleneck is classified and tied to an evidence source that can be re-run.
- The chosen tools match the symptom instead of duplicating noisy measurements.
- Before/after comparisons are explicit for any recommended optimization.
- UI-only or release-only work is separated from measurement and tracing.
Official References
- https://developer.android.com/studio/profile/overview
- https://developer.android.com/topic/performance/vitals
- https://developer.android.com/topic/performance/benchmarking/macrobenchmark-overview
- https://developer.android.com/topic/performance/benchmarking/macrobenchmark-metrics
- https://developer.android.com/topic/performance/baselineprofiles/overview
- https://developer.android.com/topic/performance/tracing
- https://developer.android.com/topic/performance/rendering/jankstats
Bundled files
FAQ
What does Android Performance Observability do?
Measure startup, rendering, memory, jank, vitals, logs, and crash signals for Android apps with actionable traces.
Who made Android Performance Observability?
krutikJain (a community member) publishes it in the krutikJain/android-agent-skills repository on GitHub.
Is Android Performance Observability free?
Yes. Android Performance Observability is open source, published by krutikJain under the MIT license.
What comes with Android Performance Observability?
Its instructions and 5 files the agent reads only when a task needs them, such as references, examples or scripts.
Which agents can use Android Performance Observability?
Any coding agent that reads SKILL.md files, including Claude Code, Codex, Cursor, GitHub Copilot and Gemini CLI. The agent loads the skill when a task matches its description.
What are agent skills?
An agent skill is a folder with a SKILL.md file: instructions that teach a coding agent how to do one kind of task, and optionally files it can read while it works. The agent keeps only the skill's name and description in mind and reads the rest when a task calls for it.
How are agent skills different from MCP servers?
An MCP server gives an agent new tools to call, code that runs somewhere and returns results. A skill gives it knowledge: how to approach a task with the tools it already has. Many agents use both.
How can my agent test my Android app?
Robomori lets coding agents create, start and control Android emulators and devices from one command, so they can install your app, take screenshots and check dark mode, font sizes and languages.
Records and analyzes Android performance data and diagnoses performance bottlenecks across user apps, system apps, and system services, even if the user does not explicitly mention profiling or traces. Use when: recording system traces, CPU call stacks, Vulkan GPU/DRM memory, or Java/native heap profiles; analyzing Perfetto traces for UI jank, frame drops, ANRs, or app startup latency issues; investigating CPU bottlenecks, IPC/Binder storms, or thread scheduling stalls; diagnosing battery drain, modem power rails, and kernel wake locks; debugging memory pressure, Low Memory Kills (LMK), OOMs, leaks, and allocation churn; performing A/B baseline trace comparisons to find regressions; executing ad hoc PerfettoSQL queries on Android traces.
Audits Android codebases for ANR risks and diagnoses ANR stack dumps. Use this skill when scanning Android code for ANR risks or triaging ANR stack dumps. Don't use for non-ANR crashes, dropped frames, general CPU profiling, or Perfetto system traces.
Diagnose and optimize Android Jetpack Compose UI code. Use this skill when analyzing performance bottlenecks of existing code to minimize recomposition overhead and prevent dropped frames and UI lag.
Analyzes Android build files and R8 keep rules to identify redundancies, broad package-wide rules, and rules that subsume library consumer keep rules. Use this skill when developers want to optimize their Android app's size, remove redundant or overly broad keep rules, or troubleshoot ProGuard configurations. Don't use for general Gradle build errors, Compose UI performance, or runtime CPU profiling.
