agentsclimarketplace
Sign in

Android emulator automation

Skill krutikJain/android-agent-skills/.github/skills/android-emulator-automation

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

Install
npx -y skills add krutikJain/android-agent-skills --skill android-emulator-automation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.0 KB, 678 tokens by cl100k_base, as published. Nobody here has run it

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

What ships with it: 10 files

20.5 KB alongside SKILL.md, 6 of them executable

agents/

references/

scripts/

Gives 0 of the 12 instructions most automation workflows skills give in 678 tokens

Counted across 745 of the 1,008 authors here whose files we hold, read 2026-08-07

  • Write conventional commit messagesin 36 of 745, across 35 files
  • Delete branches after mergein 30 of 745, across 21 files
  • Make atomic commitsin 25 of 745, across 15 files
  • Write minimal code to pass testsin 22 of 745, across 10 files
  • Re-snapshot after navigation or DOM changesin 21 of 745, across 13 files
  • Use try-catch for error handlingin 20 of 745, across 8 files
  • Run tests before committingin 20 of 745, across 12 files
  • Write tests before implementationin 20 of 745, across 8 files
  • Configure branch protection rulesin 19 of 745, across 5 files
  • Explain the why in commit messagesin 19 of 745, across 9 files
  • Refactor code while tests remain greenin 19 of 745, across 6 files
  • Interact with elements using refsin 19 of 745, across 11 files

Said here and by no other author read

  • verify sdk and boot completion before interaction
  • install or launch the explicit target package
  • dump the current ui hierarchy
  • perform the smallest interaction proving the workflow
  • redump the screen when state changes matter
  • avoid destructive shell commands or device settings changes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,851. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.