In Appium on Android, what does the UiAutomator2 setting `disableIdLocatorAutocompletion` change about an `id` locator?

## What an Android resource-id normally looks like On Android, a view declared in the app's resources gets an id that the page source reports fully qualified: package, then `:id/`, then the resource name — `com.example.scouts:id/badge_row`. Appium's `id` locator strategy matches that attribute. Because writing the package on every locator is tedious, the UiAutomator2 driver **autocompletes**: if the value you pass carries no package prefix, the driver prepends the app package before matching. A test writes `badge_row` and the driver looks for `com.example.scouts:id/badge_row`. That convenience is a default, and `disableIdLocatorAutocompletion` is the UiAutomator2 setting that switches it off. ## What changes when you turn it on - With the setting at its default, a bare value is completed with the app package and only the completed form is matched. - With the setting `true`, the driver matches the string **verbatim**, so whatever the app wrote into `resource-id` is what the locator must spell. - A value that already contains `:id/` is matched as given either way — completion only fires on a bare name. - It changes how the **driver matches**, not what the app publishes. No app rebuild is involved, and the page source is identical either way. - It is an Android concern only. iOS has no `resource-id`, so nothing on that side is package-qualified and there is nothing to complete; the XCUITest driver resolves an `id` locator onto the `name` attribute. ## Why a generated test id needs it This is where the setting stops being trivia. A scouting badge-tracker built with a cross-platform toolkit does not declare its badge rows in Android resources. The toolkit writes an identifier chosen by the app author — `badge-row-first-aid` — straight onto the view, and Appium reports it under `resource-id` as that bare string. With autocompletion on, an `id` locator of `badge-row-first-aid` is silently rewritten to `com.example.scouts:id/badge-row-first-aid`, which does not exist. The find fails while the value is plainly visible in the page source, which is exactly the kind of failure that costs an afternoon. The same shape appears whenever an identifier reaches `resource-id` from somewhere other than the Android resource system, including test tags the driver maps in. ## Where to put it It is a driver setting rather than a locator argument, so it applies to every find in the session: 1. Send it at session start inside the `appium:settings` capability map, so the whole run matches the same way. 2. Or change it later through the driver's settings API when a session genuinely needs both behaviours — rare, and worth avoiding. 3. Keep it in the Android capability profile next to `appium:automationName`, not in individual tests, so one locator never means two different things in one run. ## What it costs | | Autocompletion on (default) | `disableIdLocatorAutocompletion` true | |---|---|---| | Bare `badge_row` | matched as `com.example.scouts:id/badge_row` | matched as the literal `badge_row` | | Fully qualified value | matched as given | matched as given | | Generated id like `badge-row-first-aid` | rewritten, matches nothing | matches | | Cost | generated ids unreachable | declared ids must be written in full | The trade is straightforward: you lose the shorthand for resource-declared ids and gain the ability to address whatever the app actually wrote. Suites that address generated ids across the app turn it on for every Android session; suites that address only resource-declared ids leave it alone. ## Diagnosing the failure it fixes - The string is present in the Android page source under `resource-id`, and an `id` locator still finds nothing. - The same identifier works on the iOS run, because that side never had a package prefix to invent. - Prefixing the value by hand in one test makes it match, which confirms completion is the cause rather than a missing field. - After turning the setting on, re-check any older Android locator that relied on the shorthand, because those now need the full package form. A candidate who can name the setting, say which driver owns it, and explain that it changes matching rather than the app has answered the question. One who describes it as an iOS setting, or as something that alters what the app publishes, has not.