In Appium, what does the UiAutomator2 driver install on an Android device before a session?

## Appium does not drive Android from the host alone A newcomer's mental model is usually that the Appium server on the host reaches into the phone and manipulates it. On Android with the UiAutomator2 driver that is wrong in an important way. The driver's first act in a session is to put its own software on the device and start it, and from then on the host process is largely a proxy: it translates WebDriver requests into HTTP calls against a server that is running on the Android device itself. That one fact explains a great deal of day-to-day Appium behaviour — why sessions take seconds to start, why extra packages appear on a device after a run, why two concurrent sessions on one host need distinct ports, and why some failures show up as connection errors rather than as element-not-found. ## The pieces the driver puts on the device - **`io.appium.uiautomator2.server`** — an HTTP server packaged as an Android application and built on Android's UiAutomator accessibility APIs. It is what answers finds, attribute reads, taps and gestures. - **A companion instrumentation package** installed alongside the server, because an Android instrumentation test runner is what actually hosts and executes the server process. The server app on its own is inert. - **`io.appium.settings`** — a second helper application the Android drivers install and keep on the device. Device-level chores that the automation server cannot perform for itself are routed through it; media-projection screen recording is the clearest example. The driver installs or updates these at session start and reuses them when they are already present and current. They are Appium's own artefacts, not part of the application under test, and they outlive the session unless something removes them. ## How the host reaches the on-device server The host-side driver addresses the on-device server over a TCP port, named by the `appium:systemPort` capability. Requests arrive at the Appium server as ordinary WebDriver calls against `/session/:sessionId/...` and are forwarded to the on-device server, which does the work and returns the result back up the chain. Two consequences follow directly: 1. Each concurrent Android session on one host needs its own `appium:systemPort`; sharing one is how parallel runs collide. 2. A session can fail before a single test line runs, because getting the server installed and answering is itself a step that can time out. That failure looks like a session-creation error, not a test failure. ## Not every Appium driver works this way | Appium driver | What it puts on the device | |---|---| | UiAutomator2 (Android) | Pushes and starts its own on-device HTTP server plus a helper app | | XCUITest (Apple platforms) | Builds, installs and launches the WebDriverAgent agent app | | Official Flutter driver | Nothing; it attaches to the already-running Dart VM Service over a WebSocket | So the sentence "an Appium driver installs an agent on the device" is true of the two native drivers and false of the official Flutter one. Naming the driver is the difference between a correct statement and a confident wrong one — and naming the platform matters just as much, since WebDriverAgent is Apple's agent and has no role in an Android UiAutomator2 session. ## What this means for a real suite Take a suite driving a food-truck pre-order app across a bank of Android devices. The on-device architecture shapes several decisions: - Devices must permit installs; a locked-down device that refuses the helper packages cannot host a UiAutomator2 session at all, no matter how well the food-truck app itself is built. - Leftover Appium packages between runs are normal, not evidence of a leak. Wiping them forces a reinstall and a slower session start. - Because finds are answered on the device, the host-side driver's declarations are a description of what it forwards, not a complete contract. For a proxying driver, the on-device server is the thing that ultimately decides what a request means. - Session-start time is dominated by device-side work, so a suite that opens a fresh session for every food-truck order scenario pays that cost repeatedly. - Diagnosing a hang means asking which side stopped responding: the host driver, the on-device server, or the food-truck app under test. ## The summary an interviewer wants Appium's UiAutomator2 driver is a client-and-agent design on Android: a host-side driver plus Appium's own on-device server and helper app, connected over a port you can pin. Say that, name the packages, name the platform, and note that Appium's other drivers make different choices — that answer covers the architecture and the failure modes in one breath.