Which locator strategies does Appium's UiAutomator2 driver declare on Android?

## The list is six names long When a test in a food-truck pre-order suite asks Appium to find the "Add to order" button, the request carries a strategy name and a selector value. Appium's UiAutomator2 driver on Android declares exactly six strategies it will accept: - `xpath` - `id` - `class name` - `accessibility id` - `css selector` - `-android uiautomator` Anything outside that set is rejected by the driver rather than tried and failed, which is why a strategy borrowed from another Appium backend produces an argument error instead of a no-such-element error. Learning to read those two failure shapes differently saves a lot of time. ## What UiAutomator2 adds over its base driver The UiAutomator2 driver extends `appium-android-driver`, and that base declares five strategies — the same list minus `css selector`. So `css selector` is the one strategy the UiAutomator2 driver contributes on top of the shared Android base, and it exists for the web context rather than for native Android views. That single-item delta is a neat interview detail because it shows you have looked at the inheritance rather than memorised a list. ## What is deliberately not on the list | Strategy | Which Appium driver declares it | |---|---| | `-android uiautomator` | UiAutomator2 driver (Android) | | `-android datamatcher`, `-android viewmatcher`, `-android viewtag` | Espresso driver (Android) | | `name` | Espresso and XCUITest drivers, not UiAutomator2 | | `-ios predicate string`, `-ios class chain` | XCUITest driver (Apple platforms) | | `key` | Flutter driver | Three traps live in that table: 1. **The matcher strategies are Espresso's, not UiAutomator2's.** `-android datamatcher` and its siblings read like generic Android strategies because of the `-android` prefix, but they are the Espresso driver's alone. The prefix names a platform, not a backend. 2. **`name` is not an Android UiAutomator2 strategy.** It is declared on Apple platforms by the XCUITest driver and by Appium's Espresso driver. Reaching for it in a UiAutomator2 session is a habit carried over from iOS work. 3. **The iOS strategies do not degrade gracefully.** `-ios predicate string` in an Android session is simply not a strategy the driver knows. ## Why the list is short Every strategy has to be answerable by something concrete on the Android device. `-android uiautomator` exists because the UiAutomator2 backend can hand a selector expression to Android's own UiAutomator engine on the device and let it do the matching. `accessibility id` exists because Android exposes a content description on views. `xpath` exists because the driver can build a hierarchy document and query it. There is no strategy for a concept the backend has no way to evaluate — which is exactly why the four Appium drivers publish four different lists rather than one shared one. ## A caution about reading declared lists Appium drivers publish their strategies as an array in their source, and it is tempting to treat that array as the last word. It is a declaration, and for a driver that forwards find requests to a server running on the device, the on-device server has its own view of what it accepts. Appium's Espresso driver is the standing example of the two genuinely disagreeing: its host-side array is much shorter than what the on-device Espresso server actually implements. So: - Quote a driver's declared list as its declared list, which is what an interviewer is asking for. - Remember that for a proxying driver the effective behaviour can be broader than the declaration. - Never generalise one driver's list to another; each Appium backend is its own answer. ## Putting it to work Back in the food-truck pre-order suite, the practical shape of this knowledge is a short decision each time you write a locator for the Android UiAutomator2 session. You have `accessibility id` when the developers set a content description on the "Add to order" button; `id` when the view carries a resource identifier; `class name` when only the widget type distinguishes it; `-android uiautomator` when you need the device-side engine's own expression language; `xpath` when nothing simpler works; and `css selector` only once the session is in a web context, such as the food truck's embedded payment page. If you catch yourself reaching for `name`, `-ios predicate string` or `-android datamatcher` in that session, the mistake is not a typo — it is a strategy borrowed from a different Appium driver, and the driver will tell you so.