---
name: ansight-app-inspection-android
description: Use this skill when inspecting, debugging, verifying, or extracting evidence from a running native Android Kotlin or Java app through Ansight Studio. Prefer Ansight Studio MCP tools, then discover native Android remote app tools such as Android VisualTree, database, file-system, SharedPreferences preferences, secure-storage, reflection (`reflect.*`), artifacts, logs, telemetry, and screenshots before falling back to emulator or device access.
---

# Ansight Android App Inspection Skill

Use this skill when the target app is a native Android Kotlin or Java app paired with Ansight Studio.

Do not use this skill for React Native, .NET Android, native iOS, Flutter, server, desktop, or generic JVM projects.

## Goal

Use Ansight Studio and the paired Android app's live runtime data to inspect behavior, diagnose bugs, verify fixes, and extract evidence.

## Required Constraints

- Prefer mounted `ansight_*` MCP tools before direct emulator, device, ADB, or app-container access.
- Prefer `ansight-daemon mcp-stdio` when configuring agent access.
- Select the app and live session explicitly; do not guess when more than one live session matches.
- Pull Studio-owned state, logs, telemetry, annotations, screenshots, and artifacts before invoking remote app tools.
- Call `ansight_list_app_tools` before any `ansight_call_app_tool`.
- Only call tool ids that are present in the returned catalog.
- Prefer read-only evidence first. Use write, delete, `reflect.invoke_method`, `reflect.set_member_value`, file mutation, SharedPreferences mutation, secure-storage mutation, or overlay mutation only when the user request requires it.
- Report any fallback to direct emulator or device access and the reason Ansight could not satisfy the request.

## Default Workflow

1. Confirm Ansight Studio access.
   - Prefer mounted `ansight_*` tools.
   - If setup is required, configure `ansight-daemon mcp-stdio`.
2. Identify the target app.
   - Call `ansight_list_apps`.
   - Use `ansight_get_app` when app metadata or linked codebase metadata is needed.
3. Identify the target session.
   - Call `ansight_list_sessions` with `liveOnly=true` for live debugging.
   - Pass `appId` when known.
   - Ask the user to choose if multiple sessions match.
4. Gather host-owned evidence:
   - `ansight_get_app_state`
   - `ansight_get_logs`
   - `ansight_get_telemetry`
   - `ansight_get_annotations`
5. Discover native Android remote tools:
   - Call `ansight_list_app_tools` with the selected `sessionId`.
   - Inspect scopes, argument schemas, and guard policy.
6. Choose the narrowest tool family that answers the question.
7. Verify the behavior after any source-code fix or runtime mutation.

## Android Evidence Priority

For UI issues:

- Use native VisualTree tools when present to inspect the active Android view hierarchy, screenshots, node details, and overlays.
- Treat native VisualTree output as the rendered Android hierarchy, whether the app uses Android Views, Jetpack Compose host views, or mixed UI.
- Use screenshots and visual tree data together when layout, labels, hit targets, z-order, navigation, or visibility matter.

For persistence or local data issues:

- Use logs and telemetry first to bracket the failing time window.
- Use database tools only after listing database roots and schema.
- Use file-system tools only after listing approved roots.
- Use preferences tools for SharedPreferences only after confirming the allowed stores and keys.
- Use secure-storage tools only when the key or prefix is allow-listed.
- Use `reflect.*` tools only against registered roots from `reflect.list_roots`, and only after reading the tool schema and guard policy.

For performance and lifecycle issues:

- Use `ansight_get_telemetry` for memory, FPS, battery, timing, lifecycle, and custom channels.
- Correlate telemetry with logs, screen views, app lifecycle, screenshots, and session timing.

## Common Android Remote Tool Families

These families may be present, depending on installed artifacts and runtime guards. Do not call them unless the catalog returns them.

- VisualTree: Android view hierarchy, screenshot capture, node inspection, and diagnostic overlays.
- Database: SQLite discovery, schema inspection, and read-only queries.
- FileSystem: sandbox root listing, file reads, downloads, writes, copies, moves, and deletes.
- Preferences: SharedPreferences store and key inspection/mutation.
- SecureStorage: allow-listed secure-storage values.
- Reflection (`reflect.*`): registered live roots, member reads, opt-in `reflect.set_member_value`, and opt-in `reflect.invoke_method`.
- Artifacts: app-owned diagnostic exports.

`reflect.*` is expected to come from a Debug or explicit local-development dependency such as `ai.ansight:ansight-tools-reflection-android`. If the catalog does not expose it, report that the app may not have the development-time reflection suite enabled.

## Mutation Rules

- Do not mutate by default.
- Prefer read-only VisualTree, logs, telemetry, database reads, file reads, preferences reads, secure-storage reads, and artifact requests before mutation.
- Use overlays, SharedPreferences writes, secure-storage writes, file writes, deletes, `reflect.invoke_method`, or `reflect.set_member_value` only when the user asks for mutation or controlled test driving.
- Explain the exact mutation, target node/root/key/path, and expected rollback before making it.
- Clean up overlays and temporary files when the workflow is complete.

## Direct Emulator Or Device Fallback

Fallback only when:

- Ansight Studio is not reachable
- no matching live or captured session exists
- the required native Android tool is not exposed
- the MCP bridge or remote app tool returns a concrete blocking failure

When falling back, state whether you used emulator/device logs, `adb`, Gradle output, app data extraction, or app source inspection.

## Output Expectations

Report:

- app id and session id used
- Android application id and device/emulator observed when available
- Ansight tools called
- key logs, telemetry, screenshots, visual tree nodes, database rows, files, preferences, secure-storage values, artifacts, or reflection roots that drove the conclusion
- any mutation performed
- any exported artifact path
- verification result after the fix or action
- any fallback to direct emulator/device access and why it was necessary