In Appium on Android, why is a Jetpack Compose test tag unmatchable until you set `mapTestTagToResourceId`?

## Two descriptions of the same screen A Compose screen is described twice. Compose keeps a semantics description of its own, which is what Compose's test framework matches `Modifier.testTag` against and what the platform's accessibility services are fed from. Appium's UiAutomator2 driver reads the second description: **Android's accessibility node tree**, the same one an assistive technology consumes, which the driver serialises into the page source a locator is matched against. Those two are not the same thing, and a test tag is a Compose-side label. Unless something publishes it into a node field the driver reports, the tag exists and is completely unmatchable from Appium. The string is not merely hard to find; it is absent from the page source, which is why the usual first reaction — write a better XPath — gets nowhere. ## What the setting does UiAutomator2's `mapTestTagToResourceId` setting tells the driver to report a Compose test tag in the `resource-id` slot of the page source. Once it does: - The tag becomes visible in a page-source dump, which is the first thing to check. - Appium's `id` strategy can match it, because `id` is the strategy that matches `resource-id` on Android. - The value arrives as the **raw tag**, with no package and no `:id/`, unlike an id declared in Android resources. - Nothing about the app changes: this is a driver-side reporting decision made per session. - Compose also has its own app-side opt-in for publishing test tags into the accessibility tree; either route ends the same way, with the value reaching a field the driver reports. ## The setting that almost always travels with it Because the mapped value has no package prefix, a bare `id` locator hits the other Android default: UiAutomator2 completes an unprefixed `id` value with the app package before matching. A locator of `badge-row-first-aid` becomes `com.example.scouts:id/badge-row-first-aid` and matches nothing, even though the string is now in the page source. Turning on `disableIdLocatorAutocompletion` makes the driver match the tag exactly as written. The two settings solve different halves of one problem, and confusing them is the common stumble: 1. `mapTestTagToResourceId` decides **whether the value is reported at all**. 2. `disableIdLocatorAutocompletion` decides **how the locator you send is spelled before matching**. 3. A scouting badge-tracker built on Compose usually needs both on for its Android sessions. ## There is no iOS half of this | | Android | iOS | |---|---|---| | Driver | UiAutomator2 | XCUITest | | Tree the driver reads | Android accessibility node tree | the XCUITest element hierarchy | | Where a test tag can be reported | `resource-id`, via `mapTestTagToResourceId` | nowhere — there is no `resource-id` | | What the app must set instead | nothing extra once mapped | `accessibilityIdentifier` on the view | | Attribute a locator then matches | `resource-id`, via the `id` strategy | `name`, via `id` or `accessibility id` | The divergence is total: the Android side can be fixed with a session setting and the iOS side cannot. There, the identifier is an app change — a view has to carry `accessibilityIdentifier`, which XCUITest resolves behind the `name` attribute. No driver setting invents one. A team that plans the Android half as a settings change and forgets that the other half is a code change discovers it late. ## Working out why a tag is still missing - Dump the Android page source and search for the tag string rather than assuming where it should sit — a tag can be reported on a different node than the one you pictured. - If the string is absent entirely, the mapping is the suspect: check that the setting is on for this session, not just for the one you ran yesterday. - If the string is present but the find fails, the completion is the suspect, and prefixing the locator by hand once will confirm it. - If it works in one session and not the next, look at where the settings live: a setting sent per test rather than in the session profile makes the same locator mean two things in one run. The answer worth giving is short: Appium reads Android's accessibility node tree, a Compose test tag is not in it as an addressable id by default, `mapTestTagToResourceId` puts it there under `resource-id`, and the iOS side has to set its own identifier because none of this applies there.