In Appium, what does the `-android uiautomator` locator strategy send to the device, and who evaluates it?
answer
- a string, not compiled code
- Android only, UiAutomator2 driver
- matching happens on the device
- value starts with new UiSelector()
basics
~20 sIt sends a UiSelector expression as a plain string of chained Java-style calls. Appium's Android UiAutomator2 driver passes it to its on-device server, which parses the text and lets Google's UiAutomator framework match the live view hierarchy.
solid answer
~40 s`-android uiautomator` is an Android-only strategy declared by Appium's **UiAutomator2 driver**. Its value is a string that *looks* like Java source — `new UiSelector().resourceId("com.example.museum:id/submit")` — but nothing in your project compiles it. The driver forwards the find to `io.appium.uiautomator2.server`, the helper it installed on the device at session start; that server parses the string into real `UiSelector` calls and asks Android's UiAutomator framework to evaluate them against the live view hierarchy. So the matching happens on the phone, not in your client. Appium's Espresso driver does not declare this strategy, and there is no Apple counterpart — the XCUITest driver ships its own iOS-only dialects.
code
java · 16 linesimport io.appium.java_client.AppiumBy;
import io.appium.java_client.android.AndroidDriver;
import org.openqa.selenium.WebElement;
public final class UiSelectorFind {
private static final String SUBMIT = """
new UiSelector().resourceId("com.example.museum:id/submit")""";
private UiSelectorFind() {
}
public static WebElement submitButton(AndroidDriver driver) {
return driver.findElement(AppiumBy.androidUIAutomator(SUBMIT));
}
}go deeper
Be ready to say the selector is a string of chained UiSelector calls and that it works only on Android, through Appium's UiAutomator2 driver. Recognise an expression beginning with new UiSelector() on sight.
Explain the round trip out loud: the string leaves your client unparsed, the UiAutomator2 server on the device reads it, and Android's UiAutomator framework performs the match against the live hierarchy.
Show that you know where a bad expression fails and what the evidence looks like. A parse error returned from the device at find time is not the same signal as an element that is genuinely absent.
Own the consequence of putting matching logic on the device: the expression is untyped text no build step can check, and it ties that part of the suite to a framework Appium does not maintain.
## What the strategy actually is Appium finds an element with two things: a **locator strategy** and a **selector value**. Most strategies take something small — an id, a class name, an accessibility id. The `-android uiautomator` strategy takes something unusual: a whole **expression**, written to look like a fragment of Java source, that describes the match. ``` new UiSelector().resourceId("com.example.museum:id/submit") ``` It is declared by Appium's **UiAutomator2 driver** and it is **Android-only**. It exists because Android ships its own UI-testing framework, **UiAutomator**, whose matcher object is a class named `UiSelector`. You build one of those by chaining calls, each of which narrows what will match. This strategy is a way to hand that class's API to a device from a test written in any language: rather than shipping compiled code, Appium ships the **text of the chain** and rebuilds the object at the far end. ## Who evaluates it, step by step 1. Your test builds a find request whose strategy is `-android uiautomator` and whose value is the expression string. 2. The language client — `java-client`, the Python client, any of them — passes that string through untouched. No client carries a `UiSelector` parser. 3. The Appium server routes the find to the UiAutomator2 driver handling the session. The driver's own JavaScript does not interpret the expression's contents either. 4. The driver forwards the find to `io.appium.uiautomator2.server`, the helper application it installed and started on the device when the session began. 5. That on-device server parses the string into real `UiSelector` calls and asks Android's UiAutomator framework to evaluate them against the live view hierarchy. 6. The result travels back up the same path as an ordinary WebDriver find response — an element reference, or a not-found error. Step 4 is the one usually missing from a weak answer, and it is the one that explains everything else about the strategy. ## The consequences worth naming - **The matching runs on the phone.** The criteria are evaluated by the framework that owns the hierarchy, rather than by code running in your test process. - **Nothing type-checks the expression.** It is a string literal in your source. A misspelt matcher, a wrong argument type or a lost quote compiles cleanly and fails during the find. - **The failure message comes from the device.** When an expression is malformed, the error the driver surfaces originated in the on-device parser, not in your client. - **Escaping is doubled.** The expression contains its own string literals, which sit inside your host language's string and are then JSON-encoded into the request body. - **Nothing rewrites the value for you.** A `resourceId` matcher wants the fully qualified `package:id/name` form, because the text reaches the framework exactly as written. - **It belongs to one driver, not to Android in general.** Appium's Espresso driver answers finds with a different on-device server and a different list of strategies; being on Android does not make this dialect available. ## A quick reference | question | answer | |---|---| | Which Appium driver declares it? | the UiAutomator2 driver, on Android | | What is the selector value? | a `UiSelector` expression, as text | | Who parses that text? | the driver's on-device server | | Which framework performs the match? | Android's UiAutomator, through `UiSelector` | | Is there an Apple equivalent? | no — the XCUITest driver declares its own iOS-only strategies | ## Where it sits next to the other strategies The UiAutomator2 driver declares several strategies, and the others take a plain value that is matched directly. `-android uiautomator` is the outlier: the value is a small program, and its expressive power is exactly the expressive power of `UiSelector` — chained criteria on one node, plus two calls that move to a related node. That is why it can express matches the simple strategies cannot, and equally why an expression is harder to get right. Two framings help in an interview. First, **it is a bridge, not a query language Appium designed**: the vocabulary is Google's and Appium only carries it. Second, **the evaluation site is the whole point** — asking "where does this string get parsed?" turns most confusion about the strategy into a straightforward answer about a round trip. ## What it is not It is not compiled Java shipped to the device: there is no class file, no build step and no dependency on the app under test's own code. It is not an Appium-invented syntax: every matcher name in it belongs to Android's `UiSelector`. It is not available in an Appium session driven by another automation engine, and it is not portable to Apple platforms, where the XCUITest driver declares its own dialects for the same job. And it is not validated anywhere on the host — the first component that understands it at all is running on the device.
- Which Appium driver declares `-android uiautomator`, and does the Espresso driver have it?The UiAutomator2 driver declares it. Appium's Espresso driver does not — its finds are answered by its own on-device server, which exposes a different set of strategies. Sending a `UiSelector` expression to an Espresso session is an error, not a slower path to the same element.
- Does the Appium client validate a `-android uiautomator` string before sending it?No. The value is opaque text to the language client, to the Appium server and to the driver's JavaScript; only the UiAutomator2 server on the device parses it. A mistyped matcher therefore surfaces as a failed find at run time, with the parse error travelling back from the phone.
It is like handing a shop assistant a written description of the item you want instead of walking the aisles yourself. The search runs where the goods are, and all that comes back is what was found.
saying these in an interview costs you the question
- Says the expression is compiled Java shipped as a class file
- Thinks the -android uiautomator strategy works in an Appium iOS session
- Believes the Appium client validates the selector string before sending it
- Assumes any Android Appium driver accepts it, including Espresso
- Says the matching runs in the test process rather than on the device