android-native-crash-analysis

name	android-native-crash-analysis
description	Analyze Android native crashes through a CLI-first workflow, use AI fallback only when project resolution is incomplete, and present evidence-driven triage.

Android Native Crash Analysis

Use this skill when the task involves tombstones, logcat traces, native backtraces, ANR/crash reports with native frames, or JNI/NDK failures on Android.

CLI Discovery

• Resolve the CLI path before running any command.
• Prefer the bundled executable under this skill directory when it exists:
  • Windows x64: bin/windows-x64/ndktrace-cli.exe
  • Linux x64: bin/linux-x64/ndktrace-cli
  • macOS arm64: bin/macos-arm64/ndktrace-cli
• If no bundled executable exists, use NDKTRACE_CLI when it points to an executable file.
• If NDKTRACE_CLI is not available, use ndktrace-cli from PATH.
• In a source checkout, use a local build output such as cli/build/Debug/ndktrace-cli.exe only as a development fallback.
• Use the resolved absolute CLI path for resolve-project, validate, restore, and scan-ndk.

Workflow

• Collect the crash text, app/version context, ABI, and the richest available Android inputs: explicit NDK and symbol paths, or a project_path with optional module, variant, ABI, library name, and build hints.
• Run ndktrace-cli resolve-project first when any build input must be discovered from the Android project.
• Use CLI-selected module, variant, ABI, ndk_path, and preferred symbol output when project resolution returns resolved.
• Inspect the workspace only when resolve-project reports partial, ambiguous, or not_found, then retry the CLI with explicit paths.
• Prefer sdk.dir/ndk/<ndkVersion> when the project declares both values. Use ndktrace-cli scan-ndk only when the project metadata does not resolve a usable local NDK path.
• Prefer unstripped native outputs under build/intermediates/cxx/<variant>/**/obj/<abi>/ when selecting a .so or symbol directory.
• Run ndktrace-cli validate before symbolization when the symbol inputs are uncertain, even when they were auto-resolved from the Android project.
• Run ndktrace-cli restore to resolve frames before any root-cause explanation.
• Summarize the likely failure path, resolved project context, fallback source, evidence, and blocking gaps after deterministic restoration.

Rules

• Do not guess symbols, addresses, or source locations when the local CLI can validate or restore them deterministically.
• Treat resolve-project as the default way to discover module, variant, ABI, NDK, and symbol paths.
• Inspect Android project metadata directly only after resolve-project fails to produce a usable result.
• Treat ABI, build ID, load bias, module selection, variant selection, and symbol mismatches as blockers until they are resolved.
• Surface diagnostics when project resolution falls back, finds multiple candidate modules or variants, or cannot map the requested ABI to symbols.
• State whether ndk_path and symbol_path came from direct user input, CLI project resolution, or skill fallback before presenting conclusions.
• State the selected module, variant, ABI, ndk_path, and symbol_path before presenting conclusions when those values were auto-resolved.
• Keep conclusions tied to resolved frames, tool output, and binary evidence.
• Ask for the exact tombstone, unstripped libraries, symbol files, and build metadata when the input set is incomplete.

Output

Provide a concise incident-style analysis with:

• crash signature
• resolved project context when auto-derived local defaults were used
• fallback source when the skill had to override incomplete project resolution
• resolved native frames
• probable faulting component
• confidence level
• missing artifacts, if any