fix: address the Maps search box by id, and re-prove Phase 5

The Maps omnibox hint rotates: it read "Search here" in the Phase 5 run and
"Try petrol stations, ATMs" in the AUD-128 re-verification, so the recipe's
text match on it failed. The resource id does not rotate.

- internal/ui: add Find/FindID and the "id:" selector; Find dispatches an
  id: selector to the resource id and everything else to text as before.
- internal/recipe: wait/tap/wait_gone/tap_if and the tap helper use Find, so a
  recipe may name a resource id. Guards stay text-only.
- recipes/maps_navigate.recipe: wait/tap id:search_omnibox_text_box.
- tests for the id selector; docs and README updated.
This commit is contained in:
2026-10-17 09:12:01 +11:00
parent a7c07c645e
commit be22eba386
9 changed files with 206 additions and 26 deletions

View File

@@ -30,11 +30,15 @@ steps:
- launch
- foreground 30s
# 2. Open the search box. On the map, the box is the EditText labelled
# "Search here" (resource id search_omnibox_text_box); tapping it opens the
# search screen with the box focused and a suggestions list below it.
- wait "Search here" 30s retry 2
- tap "Search here"
# 2. Open the search box. The box is the EditText with resource id
# "search_omnibox_text_box". It is addressed by id, not by its label,
# because its label is a rotating hint: it reads "Search here" one day and
# "Try petrol stations, ATMs" the next, so a text match here broke in a
# re-verification run. The resource id is stable, and it is still a named
# match rather than a coordinate (FR-4). Tapping it opens the search screen
# with the box focused and a suggestions list below it.
- wait id:search_omnibox_text_box 30s retry 2
- tap id:search_omnibox_text_box
# 3. The search screen is a new screen, and the wedge check sits here. If the
# tap was delivered but Maps never acted on it, the screen does not change: