Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
vasilyu1983 avatar

Qa Testing Android

  • 291 installs
  • 73 repo stars
  • Updated July 13, 2026
  • vasilyu1983/ai-agents-public

qa-testing-android is a Claude Code skill that helps developers plan and execute Android application testing and QA workflows when validating mobile builds before release.

About

qa-testing-android is a mobile QA skill from vasilyu1983/ai-agents-public that steers coding agents through Android testing tasks such as structuring test plans, choosing appropriate test layers, and applying QA practices for Kotlin or Java Android projects. Developers reach for it when they need agent assistance writing or organizing instrumentation tests, UI tests, regression checks, or release verification steps without ad hoc guesswork about Android-specific tooling and conventions. The skill fits teams shipping Android apps who want consistent QA guidance embedded in their agent workflow rather than scattered checklist notes. Invoke it when Android build verification, test case design, or mobile defect reproduction appears in the task, especially alongside CI pipelines that must catch regressions before Play Store submission.

  • qa-testing-android
  • Testing & QA
  • AI-coding skill

Qa Testing Android by the numbers

  • 291 all-time installs (skills.sh)
  • +12 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #717 of 2,153 Testing & QA skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/vasilyu1983/ai-agents-public --skill qa-testing-android

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs291
repo stars73
Last updatedJuly 13, 2026
Repositoryvasilyu1983/ai-agents-public

How do you test Android apps before release?

Helps with testing & qa tasks.

Who is it for?

Android developers and QA engineers validating mobile builds who want agent-guided test planning and Android-specific QA workflows.

Skip if: iOS-only projects, backend API testing with no mobile surface, or teams already standardized on a single proprietary test framework without Android context.

When should I use this skill?

The user asks about Android testing, instrumentation tests, Espresso/UI Automator, mobile regression QA, or pre-release Android verification.

What you get

Android test plans, instrumentation or UI test scaffolding, and QA checklists aligned to mobile release gates.

  • Android QA test plan
  • instrumentation or UI test scaffolding

Files

SKILL.mdMarkdownGitHub ↗

QA Testing (Android)

Android testing automation with Espresso, UIAutomator, and Compose Testing.

Core References: Android Testing Docs, Espresso, Compose Testing

Quick Reference

TaskCommand
List emulatorsemulator -list-avds
Start emulatoremulator @<avd_name>
List devicesadb devices
Install APKadb install -r <path-to-apk>
Run unit tests./gradlew test
Run instrumented tests (connected)./gradlew connectedAndroidTest
Run instrumented tests (GMD)./gradlew <device><variant>AndroidTest
List GMD tasks`./gradlew tasks --all
Clear app dataadb shell pm clear <applicationId>

Quick Start (2026 Defaults)

  • Prefer Gradle Managed Devices (GMD) + ATD images for CI; use connectedAndroidTest for local ad-hoc runs.
  • Enable test isolation via AndroidX Test Orchestrator for instrumented tests.
  • Disable animations via Gradle testOptions (preferred) instead of per-runner ADB steps.
  • Keep selectors stable: withId() (Views), testTag (Compose), resource-id/content-desc (UIAutomator).

Recommended Gradle defaults for stable instrumented tests (version catalog names vary by project):

android {
    testOptions {
        animationsDisabled = true
        execution = "ANDROIDX_TEST_ORCHESTRATOR"
    }
}

dependencies {
    androidTestUtil(libs.androidx.test.orchestrator)
}

When to Use

  • Debug or stabilize flaky Android UI tests
  • Add Espresso tests for View-based UIs
  • Add Compose UI tests for composables
  • Add UIAutomator tests for system UI or cross-app flows
  • Set up an Android test gate in CI

Inputs to Gather

  • UI stack: Views, Compose, or mixed
  • Test layer: unit, Robolectric, instrumented UI, UIAutomator/system
  • CI target: PR gate vs nightly vs release; emulator vs device farm
  • Device matrix: min/target API, form factors, locales (if relevant)
  • Flake symptoms: timeouts, missing nodes, idling/sync, device-only issues
  • App seams: DI hooks for fakes, feature flags, test accounts/test data

Testing Layers

LayerFrameworkScope
UnitJUnit + MockitoJVM, no Android
Unit (Android)RobolectricJVM, simulated
UI (Views)EspressoInstrumented
UI (Compose)Compose TestingInstrumented
SystemUIAutomatorCross-app

Core Principles (Stability)

Device Matrix

  • Default: emulators for PR gates; real devices for release
  • Cover: min supported API level, target API level, plus tablet/foldable if supported

Flake Control

  • Prefer Gradle testOptions { animationsDisabled = true } for instrumented tests
  • Use AndroidX Test Orchestrator to isolate state and recover from crashes
  • Use IdlingResources / Compose idling + waitUntil instead of sleeps
  • Mock network with MockWebServer (or your DI fake) and avoid live backends
  • Reset app state per test (test account/data, storage, feature flags)

Writing Tests

  • Espresso (Views): open references/espresso-patterns.md
  • Compose: open references/compose-testing.md
  • UIAutomator (system/cross-app): open references/uiautomator.md

Workflows

Add a New UI Test (Instrumented)

  • Pick framework: Espresso (Views) vs Compose Testing vs UIAutomator boundary.
  • Add stable selectors: View id, Compose Modifier.testTag, system resource-id/content-desc.
  • Control externals: fake/mock network + deterministic test data.
  • Add waits: IdlingResources / Compose idling + waitUntil (avoid sleeps).
  • Run locally: ./gradlew connectedAndroidTest (or a single test via runner args).

Diagnose a Flaky Instrumented Test

  • Confirm reproduces: run the test 10x; isolate to one device/API if needed.
  • Remove nondeterminism: network, clock/timezone, locale, feature flags, animations.
  • Replace sleeps with idling/explicit waits; validate your IdlingResource actually idles.
  • Capture artifacts: logcat + screenshot + screen recording for failures.
  • If still flaky, isolate app state (orchestrator + clear data) and bisect the interaction steps.

Add a CI Gate (Preferred: GMD)

  • Configure GMD + ATD images (see references/gradle-managed-devices.md).
  • Run PR gate on a small matrix; expand via groups for nightly/release.
  • Ensure artifacts upload on failure: **/build/reports/androidTests/, screenshots/logcat.

ADB Commands (Triage)

# Screenshot
adb exec-out screencap -p > screenshot.png

# Screen recording
adb shell screenrecord /sdcard/demo.mp4

CI Integration

Preferred: Gradle Managed Devices (GMD). See references/gradle-managed-devices.md.

# .github/workflows/android.yml
name: Android CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
      - uses: gradle/actions/setup-gradle@v3
      - run: ./gradlew test pixel6api34DebugAndroidTest

Navigating References

The reference guides are intentionally large; search within them instead of loading everything:

  • rg -n \"^## \" frameworks/shared-skills/skills/qa-testing-android/references/compose-testing.md
  • rg -n \"Idling|waitUntil|Synchronization\" frameworks/shared-skills/skills/qa-testing-android/references/compose-testing.md
  • rg -n \"RecyclerView|Intents\" frameworks/shared-skills/skills/qa-testing-android/references/espresso-patterns.md

Do / Avoid

Do

  • Prefer orchestrator + per-test isolation for instrumented tests
  • Use IdlingResources / waitUntil for async waits
  • Use Robot/Page Object patterns for readability and reuse
  • Run a small device matrix on PRs; expand on nightly/release

Avoid

  • Thread.sleep() for synchronization
  • Tests depending on live network/backends
  • Flaky selectors (localized text, position-only selectors)

Resources

ResourcePurpose
references/espresso-patterns.mdEspresso matchers, actions
references/compose-testing.mdCompose testing guide
references/uiautomator.mdUIAutomator patterns (system UI)
references/gradle-managed-devices.mdManaged Devices for CI
references/screenshot-testing.mdVisual regression for Android
references/test-orchestrator-patterns.mdAndroidX Test Orchestrator patterns
references/android-ci-optimization.mdCI pipeline optimization
data/sources.jsonDocumentation links

Templates

TemplatePurpose
assets/template-android-test-checklist.mdStability checklist

Related Skills

SkillPurpose
software-mobileAndroid development
qa-testing-strategyTest strategy
qa-testing-mobileCross-platform mobile

Fact-Checking

  • Use web search/web fetch to verify current external facts, versions, pricing, deadlines, regulations, or platform behavior before final answers.
  • Prefer primary sources; report source links and dates for volatile information.
  • If web access is unavailable, state the limitation and mark guidance as unverified.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.