Auto-Setup Espresso UI Tests for Your Android App

Standing up Espresso UI tests for a native Android app by hand is slow — read your screens,
decide which matter, tag every element with a stable `android:id` or `testTag`, write a base
test class, wire the app to a test backend, and fight the Gradle and emulator quirks
(Orchestrator, R8/minify, dependency skew, `10.0.2.2`, Play-Services AVDs) that make
instrumented tests flaky. **This skill does all of that wiring for you.** Point it at your
project root; it reads how your app is built and generates a complete, runnable Espresso suite
— then tells you exactly how to run it.

### ✅ What you get
- **Screen discovery + curation** — Activities, Fragments, AndroidX Navigation, Compose; *you* pick which matter
- **An `android:id` / `testTag` tagging plan** — XML and Compose, with the matcher caveats baked in
- **A shared `BaseInstrumentedTest.kt`** — mock-server seam, error-injection helpers, and `loginViaUi()`
- **One happy-path spec per screen** — asserting by stable id, never visible text
- **Server-side error-state specs** — when a mock server is available, driven via `/__mock/*`
- **The Gradle stability config** — Test Orchestrator + `clearPackageData`, aligned deps, no debug minify (approval-gated)

### 🔌 How it connects to your backend
The test build points your app's API base URL at a mock server (or your test backend) via an
`apiBaseUrl` instrumentation argument the app reads at startup. The emulator reaches the host
machine's `localhost` at **`10.0.2.2`** — never `localhost` (that is the emulator itself).
Specs drive the mock's `/__mock/*` control API over `HttpURLConnection` — no in-app changes.

### 🧩 Works on its own — better with a mock server
On its own it stands up the **happy-path** specs and the base test class — that's the
auto-setup, done, no extra purchase needed. For **deterministic, offline runs and
server-side error-state** coverage, add a mock server exposing the `/__mock/*` control API:
the companion skill **Bootstrap Mobile Mock Server** scaffolds exactly that. No mock server?
This skill asks how you'd like to proceed and scaffolds the happy-path suite right away; add
the mock server later and re-run to generate the error-state specs.

### 🛡️ Safe by default
It shows the full plan and asks before writing anything. The only source edits it makes are
`android:id` / `testTag` props — **no refactors, no logic changes.** The default login
strategy (`ui-login`) touches no app source. `build.gradle` is only ever touched with a
**separate, explicit approval**, and only for the test-stability config — never any other DSL.

### 🧪 Why it works
Distilled from a **production Android testing harness used on real shipping apps**, so it bakes
in the conventions that keep Espresso suites stable:
- `withId` / `testTag` matchers over brittle text, with `AmbiguousViewMatcherException` scoped from an ancestor
- The `launchFragmentInContainer` theme-resolution gotcha + the host-Activity launch fallback
- Instrumentation-arg mock wiring with `10.0.2.2` (the emulator's host address)
- The Gradle stability set: Test Orchestrator + `clearPackageData`, debug `minifyEnabled false`, `androidx.test` alignment
- The Play-Services AVD blocker (a `google_apis` image without the Play Store crashes those screens)

### ▶️ What you run
It **scaffolds and instructs** — writes the suite and prints the exact
`./gradlew connectedDebugAndroidTest` command. You run them.

### 📋 Requirements
- A native Android project (Kotlin/Java, XML or Compose)
- Android SDK + adb, the Gradle wrapper, a JDK, and an emulator or device

---
*Built for Android developers and QA engineers who want a real Espresso E2E suite stood up in
minutes instead of days.*