agentleFS
GuillemRocaGuillemRoca/agent-skills-android/skills/debugging-and-error-recovery/SKILL.md

debugging-and-error-recovery

Skill2 starsChanged 40 days agoMITView on GitHub

Use when encountering unexpected behavior, crashes, or test failures in Android. Six-step triage from reproduction to regression guard, using Logcat, Android Studio debugger, and profiling tools.

68 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use minimalist-ui, web-design-guidelines and 3 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • AnasX7Skill

    minimalist-ui

    Clean editorial-style interfaces. Warm monochrome palette, typographic contrast, flat bento grids, muted pastels. No gradients, no heavy shadows.

    Also in 3 projects that use this

  • VercelSkill

    web-design-guidelines

    Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".

    Also in 6 projects that use this

  • MicrosoftSkill

    playwright-cli

    Automate browser interactions, test web pages and work with Playwright tests.

    Also in 4 projects that use this

  • VercelSkill

    vercel-react-best-practices

    React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.

    Also in 4 projects that use this

  • JetBrainsSkill

    webapp-testing

    Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 7 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 60 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test failure (unit or instrumented)

    line 18
  2. Distinctive:

    Stop-the-Line: When you encounter unexpected behavior, stop feature work.

    line 23
  3. Very specific:

    When the android CLI is available, use it for the fastest possible state capture before doing anything else:

    line 42
  4. Distinctive:

    Use conditional breakpoints for intermittent issues

    line 84
  5. Distinctive:

    Check the call stack for unexpected callers

    line 86
  6. Distinctive:

    Remove unrelated code paths

    line 91
  7. Distinctive:

    Use hardcoded data instead of API responses

    line 92
  8. Very specific:

    If it's a Compose issue, test in a @Preview

    line 94
  9. Distinctive:

    No reproduction steps documented

    line 201

“Common” is measured: kept by at least 6 in 10 of the 60 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Debugging and Error Recovery

Overview

"Stop-the-Line Rule: when unexpected behavior occurs, halt feature work." Debugging is systematic, not guesswork. Reproduce the bug, localize the cause, reduce to the simplest case, fix the root cause (not the symptom), guard against regression, and verify the fix.

When to Use

  • Unexpected crash or exception
  • Test failure (unit or instrumented)
  • Behavior that doesn't match the spec
  • Performance regression (jank, slow startup)
  • Build failure after seemingly unrelated changes

Stop-the-Line: When you encounter unexpected behavior, stop feature work. Errors compound — a bug in step 3 makes steps 4–10 wrong.

Core Process

Step 1: Reproduce

  1. Reproduce the bug reliably:
    • Same device/emulator? Same API level? Same data?
    • What sequence of actions triggers it?
    • Does it happen every time or intermittently?
  2. Capture the environment:

    Device: Pixel 7 (API 35) / Emulator (API 26)
    Build: debug / release
    Steps: Open app → Navigate to Tasks → Tap "Add" → Crash
    Frequency: Every time / ~30% of the time

    When the android CLI is available, use it for the fastest possible state capture before doing anything else:

    android info                                     # SDK location, JDK, env (rules out wrong-toolchain bugs)
    android screen capture -o repro.png              # what the user sees right now
    android layout --pretty --output=repro.json      # full UI tree (resource-ids, text, bounds, role)

    Three artifacts in <5 seconds, pre-debugger. Attach them to the bug report or commit them to a repro/ scratch dir before iterating. See ../../references/android-cli-reference.md.

Step 2: Localize

  1. Read the error output carefully:

    Logcat:

    # Filter to your app
    adb logcat -s "YourApp:D" "AndroidRuntime:E"
    
    # Filter by tag
    adb logcat -s TaskViewModel:D
    
    # Search crash logs
    adb logcat "*:E" | grep -i "fatal\|crash\|exception"

    Common crash signatures:

    SignatureLikely Cause
    NullPointerExceptionNull not handled, !! used incorrectly
    IllegalStateException: Already resumedCoroutine resumed twice
    IllegalStateException: Fragment not attachedLifecycle mismatch
    SQLiteConstraintExceptionPrimary key or unique constraint violation
    NetworkOnMainThreadExceptionMissing withContext(Dispatchers.IO)
    DeadObjectExceptionProcess death during IPC
    WindowManager$BadTokenExceptionDialog shown after Activity destroyed
    ClassCastExceptionWrong type in Bundle/Intent extras
    OutOfMemoryErrorImage not resized, large dataset in memory
    ANRMain thread blocked >5 seconds
  2. Use the Android Studio debugger:
    • Set breakpoints at the suspected location
    • Use conditional breakpoints for intermittent issues
    • Evaluate expressions in the debugger console
    • Check the call stack for unexpected callers

Step 3: Reduce

  1. Simplify to the minimal reproduction case:
    • Remove unrelated code paths
    • Use hardcoded data instead of API responses
    • Isolate the component (test in isolation)
    • If it's a Compose issue, test in a @Preview
  2. Binary search for regressions:
    # Find the commit that introduced the bug
    git bisect start
    git bisect bad          # Current commit is bad
    git bisect good abc123  # Last known good commit
    # Git will checkout commits for you to test
    ./gradlew test
    git bisect good  # or: git bisect bad
    # Repeat until the culprit commit is found

Step 4: Fix

  1. Fix the root cause, not the symptom:
// SYMPTOM FIX (bad): catch and ignore
try {
    repository.syncTasks()
} catch (e: Exception) {
    // Swallow the error — user never knows
}

// ROOT CAUSE FIX (good): handle the specific error
try {
    repository.syncTasks()
} catch (e: IOException) {
    _uiState.update { it.copy(error = "Network unavailable. Showing cached data.") }
}
  1. Common Android fixes:
BugFix
Crash on configuration changeSave state in SavedStateHandle
Memory leakRemove callback in onCleared(), use viewModelScope
Stale data after process deathRestore from SavedStateHandle or Room
Race condition in coroutinesUse Mutex or MutableStateFlow.update { }
Recomposition loopCheck derivedStateOf, stable types, lambda captures
ANRMove work off main thread with withContext(Dispatchers.IO)

Step 5: Guard

  1. Write a regression test using the Prove-It pattern:
@Test
fun `task sync handles network error without crashing`() = runTest {
    // Arrange: simulate the bug condition
    coEvery { api.getTasks() } throws IOException("timeout")

    // Act
    repository.syncTasks()
    advanceUntilIdle()

    // Assert: verify the fix behavior
    val state = viewModel.uiState.value
    assertIs<TaskListUiState.Error>(state)
    assertEquals("Network unavailable. Showing cached data.", state.error)
}

Step 6: Verify

  1. Full verification:
    • ./gradlew test — all unit tests pass
    • ./gradlew connectedAndroidTest — instrumented tests pass
    • ./gradlew assembleDebug — builds successfully
    • Manual reproduction steps no longer trigger the bug
    • Related functionality still works

Debugging Tools Reference

ToolUse For
LogcatRuntime logs, crash traces, system messages
Android Studio DebuggerBreakpoints, watches, expression evaluation
Layout InspectorCompose hierarchy, recomposition counts
Network ProfilerAPI call inspection, timing, payload
CPU ProfilerThread activity, method traces, jank detection
Memory ProfilerHeap dumps, allocation tracking, leak detection
LeakCanaryAutomatic memory leak detection
Firebase CrashlyticsProduction crash reports, trends, affected users
StrictModeDetect disk/network on main thread during development
Systrace / PerfettoSystem-level performance tracing

Common Rationalizations

ShortcutWhy It Fails
"Just add a try-catch and move on"You've hidden the bug. It will resurface in a worse form.
"It works now after a clean build"Build caching bugs are real, but if you can't explain why it works, it might not.
"It's a flaky test, just re-run it"Flaky tests have a root cause: timing, state leakage, or shared resources. Fix it.
"I'll investigate later"Errors compound. A bug in step 3 makes steps 4-10 wrong. Stop the line.
"The error message says X, so the fix is Y"Error messages from untrusted sources shouldn't be blindly followed. Verify.

Red Flags

  • Generic catch (e: Exception) swallowing errors
  • Thread.sleep used to "fix" timing issues
  • Bug fix without regression test
  • Fix addresses symptom, not root cause
  • @Ignore added to failing tests
  • No reproduction steps documented
  • Fix changes unrelated code ("while I'm here...")

Verification

  • Bug reproduced reliably before fixing
  • Root cause identified (not just symptom)
  • Regression test written (Prove-It pattern)
  • ./gradlew test passes
  • ./gradlew assembleDebug succeeds
  • Manual reproduction confirms fix
  • No unrelated changes in the fix

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.