Espresso Backend

## Two drivers, two architectures Android has two Appium drivers and they are not two implementations of one idea. Appium's **UiAutomator2 driver** pushes a prebuilt server that runs in its own process and works across the device. Appium's **Espresso driver** compiles a server per app with Gradle, signs it to match that app, and runs it **inside the app's process** as an Android instrumentation package. Every part of the choice follows from that one line. ## What the in-process server buys - `mobile: registerIdlingResources` — the app's own busy state governs the driver's commands, instead of the driver inferring quiescence from outside. - `mobile: backdoor` — a call into a method on an object in the running app, for setup the UI would make long and fragile. - The driver's matcher-based find strategies — `-android datamatcher`, `-android viewmatcher`, `-android viewtag` — reach app-side constructs, including list rows an adapter has not rendered, that an outside observer cannot see. None of these three has an equivalent on the UiAutomator2 driver, and the reason is not that nobody implemented one. There is no seam from another process. ## What it charges - **A Gradle build per app.** The first session against a new app build compiles the server; the driver caches it, and `appium:forceEspressoRebuild` gives that saving back when the cache goes stale. - **A shared signature.** Android only lets an instrumentation package attach to a target it shares a signing certificate with, so the app must be one you can rebuild or at least re-sign. - **An Android build toolchain wherever sessions start**, CI runners included. - **A boundary at the app's edge.** An in-process server is bounded by that process, so the notification shade, the launcher, a second app and the system settings screen are not this driver's ground. - **Coupling.** Whatever part of the suite uses the in-process surface runs under this driver and no other. ## Side by side | | Appium's UiAutomator2 driver | Appium's Espresso driver | |---|---|---| | reach | device-wide | inside the app under test | | server | prebuilt and pushed | compiled per app with Gradle | | app requirement | none beyond installability | rebuildable and signature-matched | | in-process hooks | none | idling resources, backdoor, matcher finds | | session start | fast | the first one pays a build | ## A decision procedure 1. **Map the journeys.** If any leaves the app — a push notification tapped from the shade, a hand-off to the camera app, a system permission screen — those cases belong on the UiAutomator2 driver whatever else you decide. 2. **Check the artefact.** Can you rebuild, or at least re-sign, what you test? If the answer is no, the choice has already been made for you. 3. **Ask what you are fighting.** If the pain is intermittent failure around the app's own background work, or reaching data the UI has not rendered, that is exactly what the in-process surface addresses. If the pain is elsewhere, the build cost buys nothing. 4. **Price the build.** Count it per pipeline run, not per session: one cold build plus a warm cache is usually acceptable, a cold build per session usually is not. 5. **Then choose**, and be willing to run both drivers for different slices of the suite rather than forcing one onto journeys it cannot reach. ## Keeping a suite that can still move Both Android drivers answer finds by `id`, `class name`, `accessibility id` and `xpath`, so a page layer built on those strategies ports between them. What does not port is the in-process surface. The practical shape is to keep that surface behind a small interface with a second, UI-driven implementation for UiAutomator2 sessions — the suite then degrades rather than breaks when it has to run against an artefact it cannot rebuild. For a wind-farm inspection app this usually splits cleanly. The bulk of the suite lives inside the app — inspection forms, turbine lists, offline report queues — and is exactly where the Espresso driver's reach pays for its build. A thin band of cases does not: the push notification a technician taps to open a work order, the hand-off to the camera, the system location prompt. Those belong on the other driver, and pretending otherwise produces a case that cannot be written rather than one that is merely awkward. The honest summary is that the Espresso driver is right for a team that owns the Android app, builds it in the same pipeline that runs the tests, and spends its time inside it. It is wrong for a suite that roams the device, or one pointed at a build somebody else signed. Teams get into trouble by treating the two as interchangeable and discovering the difference at the point where a test needs to leave the app.