agentleFS
Sign inStart free
krutikJainkrutikJain/android-agent-skills/.github/skills/android-emulator-automation/SKILL.md

android-emulator-automation

Skill14 starsChanged 8 months agoMITView on GitHub

Use semantic ADB and UIAutomator workflows to inspect, launch, and interact with Android apps from agents.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the request is about: android emulator automation, adb semantic ui automation, uiautomator dump and tap.

    line 17
  2. Very specific:

    Verify the Android SDK, adb, the target device or emulator, and boot completion before attempting interaction.

    line 25
  3. Distinctive:

    Prefer semantic selectors to pixel coordinates.

    line 32
  4. Distinctive:

    Treat automation as an inspection and smoke tool, not a replacement for deterministic UI tests.

    line 33
  5. Distinctive:

    Verify device state, package name, and boot completion before issuing input commands.

    line 34
  6. Distinctive:

    Keep the scripts safe for CI by avoiding destructive shell commands or device-wide settings changes.

    line 35

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Android Emulator Automation

When To Use

  • Use this skill when the request is about: android emulator automation, adb semantic ui automation, uiautomator dump and tap.
  • Primary outcome: Use semantic ADB and UIAutomator workflows to inspect, launch, and interact with Android apps from agents.
  • Reach for this skill when an agent needs to launch an APK, inspect the current screen, or perform a deterministic interaction without writing Espresso or Compose UI tests.
  • Handoff skills when the scope expands:
  • android-testing-ui
  • android-permissions-activity-results

Workflow

  1. Verify the Android SDK, adb, the target device or emulator, and boot completion before attempting interaction.
  2. Install or launch the target app with explicit package awareness so the request stays tied to the right artifact.
  3. Dump the current UI hierarchy and prefer semantic selectors such as text, content description, or resource ID over raw coordinates.
  4. Perform the smallest interaction that proves the workflow and re-dump the screen when state changes matter.
  5. Hand off long-lived regression coverage to UI tests once the automation path is understood.

Guardrails

  • Prefer semantic selectors to pixel coordinates; only fall back to coordinates when the UI tree is missing the required metadata.
  • Treat automation as an inspection and smoke tool, not a replacement for deterministic UI tests.
  • Verify device state, package name, and boot completion before issuing input commands.
  • Keep the scripts safe for CI by avoiding destructive shell commands or device-wide settings changes.

Anti-Patterns

  • Hard-coding coordinates when text or resource IDs are available.
  • Running emulator commands before the device is boot-complete.
  • Treating flaky one-off automation as proof of a stable UI workflow.
  • Mixing app install, interaction, and log scraping into one opaque script with no intermediate output.

Examples

Happy path

  • Scenario: Build the Compose fixture, install it on an emulator, and dump the current OrbitTasks screen.
  • Command: bash skills/android-emulator-automation/scripts/run_examples.sh

Edge case

  • Scenario: Launch a preinstalled app and target a single semantic control without relying on screen coordinates.
  • Command: python3 skills/android-emulator-automation/scripts/navigator.py --find-text "Blocked" --tap

Failure recovery

  • Scenario: Confirm the device is discoverable and UIAutomator can dump the hierarchy before chasing a selector bug.
  • Command: python3 skills/android-emulator-automation/scripts/device_health.py --json

Done Checklist

  • The target package, device serial, and current screen are explicit.
  • Semantic selectors were preferred over coordinates.
  • The automation path is reproducible in local development and CI.
  • The request hands off to UI testing when the workflow needs regression coverage.

Official References

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.

Check your setup, free