Your Appium Espresso `-android datamatcher` find for a hedgerow-survey row fails though the row is on screen — how do you triage it?

## Where an Espresso-driver find is actually answered Appium's Espresso driver runs only on Android. At session start it builds an Espresso server that lives inside the app under test, and it proxies most commands — element finds included — to that server rather than answering them on the Appium host. Two consequences matter for triage. First, the node-side driver's declared strategy array is not the effective list: the on-device server's own strategy enum is, and that enum is what accepts `-android datamatcher`, `-android viewmatcher` and `-android viewtag`. Second, when a `-android datamatcher` find fails, the failure happened **inside your app's process on the device**, not in your client, so the useful evidence is the on-device server's exception surfaced through the driver log. ## What `-android datamatcher` is asking for The selector value is a JSON object — `name`, `args`, and optionally `class`. The on-device server reads it, builds the matcher it describes, and passes that matcher to Espresso's `onData`. `onData` is the half people skip. It does not query the view tree. It searches the **data set behind an `AdapterView`** — the objects the adapter is holding — picks the one your matcher accepts, causes the corresponding row to exist, and only then yields it. That is the whole reason the strategy is on this Android driver: it addresses rows that were never inflated. It is also why "but the row is right there on screen" is not evidence when the find fails. ## The three layers a failure can live in 1. **Wrong container.** `onData` is defined over an `AdapterView`. If the hedgerow-survey species list is built on one of Android's newer recycler-style list widgets — which are not `AdapterView` subclasses — no `-android datamatcher` selector will ever match, however correct the JSON. The fix is not a better matcher; it is `-android viewmatcher`, which goes through `onView` against the rendered hierarchy. 2. **Unresolvable matcher JSON.** The object is resolved reflectively on the device. A misspelled `name`, an `args` list whose types do not fit the method's parameters, or a static method that does not live where the server looks unless you name it in `class` — all of these fail on the device, at run time, with nothing in your test code to warn you. 3. **A matcher that is valid but aimed wrong.** This is the subtle one. `onData` hands your matcher a **data object**, not a view. A matcher describing a view property will be offered survey records instead and will accept none of them. The JSON is well-formed, the class resolves, and the result is still zero matches. ## A triage order that converges - Establish the container first. If the Android list is not an `AdapterView`, stop; the strategy is inapplicable and you switch dialects rather than debug the selector. - Check that `class` is present whenever the matcher's static method is not on the class the on-device server searches by default. A missing `class` and a misspelled `name` produce similar-looking failures. - Sanity-check the types in `args`, not just the values — a string where a number is expected fails at reflection time. - Ask what the matcher is being handed. If it describes a view attribute, it is the wrong kind of matcher for `onData`; rewrite it against the adapter's item type, or move to `-android viewmatcher`. - Loosen the matcher until it matches something, then tighten it. A matcher that suddenly matches many rows tells you the shape is right and the predicate is too broad; one that still matches nothing tells you the shape is wrong. - Read the driver log rather than the client stack. Because the find is answered on the device, the informative text is the on-device server's, and it usually distinguishes failing to build the matcher from failing to find data. ## What to conclude, and what not to The instinct this failure punishes is treating `-android datamatcher` as a fancier way to say `id`. It is not a selector over the screen at all; it is a query over an adapter's model, expressed as JSON and executed as reflection inside your own Android app. Two habits follow. Keep matcher JSON short and written against the item type you actually put in the adapter, so a failure reads as a model mismatch rather than a puzzle. And keep the two dialects separate in your head: `-android datamatcher` for the adapter's data, `-android viewmatcher` for views Espresso can already see. Reaching for the first when you meant the second is the most common way a hedgerow-survey find fails with the row plainly visible. One last note on evidence. Because this is Android's Espresso driver and not its UiAutomator2 driver, none of the usual UiAutomator2 tuning applies here, and there is no Apple-platform analogue to compare against — the reach `onData` gives you is a property of running inside the app's process, which the Espresso driver does and the other Appium drivers do not.