Android replay: non-unique framework id `android:id/title` used as primary identity → systematic false divergences (FDR 1.0)

[thymikee]

Summary

On Android, replay of native list UIs produces systematic false divergences (measured FDR 1.0
across two independent Settings flows) because the annotator selects the non-unique framework
resource-id android:id/title as the primary identity for list-row text. iOS is unaffected (FDR 0),
because its AX cells expose unique per-cell identifiers.

This was found during a controlled false-divergence experiment (wave-3 E1) on main @ 6efe54451
(daemon v0.19.3). The app is unchanged between record and replay — every divergence here is false by
construction.

Root cause (from the divergence targetBinding)

A recorded Android get/press on a list row annotates like:

get "text" "id=\"android:id/title\" || role=\"textview\" label=\"Network & internet\" || label=\"Network & internet\""
# target-v1: { "id":"android:id/title", "role":"textview", "label":"Network & internet",
#             "sibling":1, "viewportOrder":1, "ancestry":[linearlayout, recyclerview, framelayout, ...] }

• android:id/title is a shared framework resource-id present on every titled row — on the Settings
  root it matches 11 elements (matchCount: 11).
• The recorded ancestry is label-less generic container roles (linearlayout / recyclerview /
  framelayout), so it contributes no disambiguation — leaving only sibling/viewportOrder position.
• On replay the position→element mapping shifts (a conditional row appears, or the shared-id set
  reorders), so the id-path resolves the wrong element. The identity verifier then catches the label
  mismatch and refuses:

targetBinding: {
  classification: "identity-mismatch",
  matchCount: 11,
  recorded: { id: "android:id/title", role: "textview", label: "Network & internet" },
  observed: { id: "android:id/title", role: "textview", label: "Apps" },
  mismatches: [ "label: recorded=Network & internet observed=Apps" ]
}

This is a safe failure, not a silent mis-bind

The verifier did the right thing — it prevented acting on the wrong element ("Apps") and failed loudly.
The cost is a false divergence, not a wrong action. So the fix belongs upstream in Android identity
selection, not in loosening the verifier.

Proof it's the shared id (not Android capture)

The same flow with label="..."-only selectors (no android:id/title) replays 3/3 clean. Android
capture and the label resolver are fine; the defect is choosing a non-unique framework id as primary.

Reproduction

1. Build a daemon from main. On an Android emulator, record a native list flow, e.g. Settings root:
   open com.android.settings --relaunch --save-script=f.ad, then get text 'label="Network & internet"',
   get text 'label="Connected devices"', close --save-script.
2. replay f.ad → REPLAY_DIVERGENCE / identity-mismatch at the first get; the recorded selector
   leads with id="android:id/title".
3. Hand-author the same flow with label="..."-only gets → replays clean, repeatedly.

Measured (wave-3 E1, 20 replays/flow, unchanged app)

Flow	Platform	FDR
Settings → General → About	iOS native	0.00 (20/20 clean)
test-app Form fill	iOS RN	0.00 (20/20 clean)
Settings/Battery (default annotation)	Android native	1.00 (20/20 diverge)
Settings root, label=-only selectors	Android native	0.00 (3/3 clean)

Recommendation

At annotation time on Android, do not use a non-unique resource-id as the primary identity selector:

• Treat framework/shared ids (namespace android:id/*, and any id whose match-count > 1 at capture) as
  non-selective — demote below the visible label, or omit them from the selector chain.
• Equivalently, the resolver could treat a clause that matches N > 1 and requires positional
  disambiguation as low-confidence and fall through to a more selective later clause (the label clause
  here resolves uniquely and correctly).

Either change makes Android native-list replay resolve by the (unique) label and eliminates this class of
false divergence — the single highest-leverage replay-robustness fix for Android.

Secondary (same experiment, lower priority)

A viewport-bottom element (y≈2864 of 2992) intermittently fell outside the captured tree, causing
wait/action-failure divergences — a capture-completeness question worth a separate look.

---

Found via wave-3 E1 false-divergence experiment. Evidence artifacts (divergence JSONs with targetBinding,
the clean label=-only fixture, per-flow summary.json) available on request.

[thymikee]

Implementation guidance (from review) — sharper than the original writeup

The defect poisons TWO distinct things; the fix must land in both. A non-unique recorded id corrupts:

1. The selector chain — resolution binds the wrong row (matchCount: 11, then positional tiebreak → "Apps").
2. The target-v1 identity tuple — per ADR-0012 decision 3 ("id when recorded, else role+label"), local identity keys on the id, so all 11 rows share identity and only brittle position can discriminate at verify time.

Fixing only the annotation still leaves resolution binding wrong via the chain; fixing only the chain still leaves verification keyed on a non-selective identity. Both must demote the non-unique id.

Prefer the writer-side fix, not the resolver-side alternative. The "resolver treats an N>1 clause as low-confidence and falls through" option changes live resolveSelectorChain semantics for every press/fill — which ADR-0012 deliberately left untouched (disclosed-not-changed disambiguation). The annotation / chain-construction fix is surgical and replay-scoped.

Generalize beyond android:id/*. The namespace is a heuristic; the load-bearing rule is capture-time uniqueness — "any id whose match-count > 1 in the record-time tree." This is not Android-only in principle: an RN FlatList reusing one testID across rows reproduces the same class on iOS. The fix PR should carry an iOS/RN duplicated-testID fixture to pin that.

The uniqueness signal already exists at the right spot. computeTargetEvidence (src/daemon/session-target-evidence.ts:42) already computes the disambiguation domain over the record-time tree — the identity-set size is available at annotation time. Omit id from identity (fall back to role+label) when that set size > 1; buildSelectorChainForNode needs the equivalent check for the chain.

This is an ADR-0012 amendment, not just a bug fix. Decision 3's "id when recorded" carries an unstated, now-measured-false assumption: that a recorded id is selective. One sentence belongs in the fix PR / ADR: an id may serve as identity (and lead the selector chain) only when it uniquely denotes the target in the record-time tree.

---

Rigor follow-ups (not blockers for the fix):

• The label-only control arm was 3 runs vs the default arm's 20 — I'm re-running it to n=20 before quoting the comparison in any writeup.
• FDR 1.0 at the first diverging step means downstream steps went unmeasured, so the flow-level 1.0 may hide additional divergence classes on later steps.
• The secondary viewport-bottom capture-completeness observation is being split into its own issue (different subsystem).

[thymikee]

Rigor follow-up resolved: the label-only control now runs at n=20 (equal to the default arm), on a warm daemon with no concurrent load:

Arm	n	Clean	Diverge	FDR
default annotation (leads with android:id/title)	20	0	20	1.00
label-only selectors (no android:id/title)	20	20	0	0.00

The differential holds at equal n — the non-unique framework id is the whole defect. (An earlier n=20 attempt read 0/20 clean but was invalid: the emulator crashed mid-run and every replay failed at step-1 DEVICE_NOT_FOUND, wrapped as replay failures — not a label-only refutation. A no-annotation flow can't produce identity-mismatch anyway.)

[thymikee]

Correction to my "rigor follow-up resolved / differential is airtight" comment above — it was wrong, and the proper control changes the conclusion.

You were right: the label-only control carries no target-v1 annotations, so the verifier is switched off in that arm. 20/20 clean there proves label-resolution is stable — not that the proposed fix (demote the non-unique id, verification live) yields FDR 0. I over-claimed on the satisfying half.

The arm that actually simulates the fix — the recorded .ad with the id stripped from both the selector chain and the target-v1 identity tuple, verifier live on role+label+ancestry+position — now run at n=20:

Get class (the #1269 core): id-demotion FIXES it — measured

• get-only stripped-id (id gone, verifier live): 20/20 clean, FDR 0.00 (equal n to the default arm's 20/20 diverge).
• Demoting the non-unique id lets the get resolve+verify on the selective label → clean. The filed fix is necessary and sufficient for gets.

But a second, distinct class surfaced — id-demotion does NOT fix it

The confounded full-flow stripped-id fixture still diverged, at the press "role=\"linearlayout\"" step ("Connected devices"):

identity-mismatch, matchCount: 12, recorded={role:linearlayout} observed={role:linearlayout} mismatches:[]

Same "disambiguation isolated a different element" mechanism — but this target has no id to demote: the row's clickable node is a label-less LinearLayout, the visible label lives on a child. So Android list presses are a separate defect — a non-selective container role, not a shared id.

Net correction to the fix scope

#1269's id-demotion resolves the Android list-get false-divergence class (measured, n=20). It does not address list-presses, whose clickable containers carry no selective identity at all. Both are the same spirit (non-selective identity → unstable positional disambiguation) but need different fixes: gets → demote the non-unique id (fall to label); presses → derive identity from the labeled descendant / resolve the press to the labeled node. The fix PR should carry both, or spawn a sibling issue for the press class — rather than let "id-demotion fixes Android list flows" stand.

Evidence: settings-android-strippedid-getonly.ad (20/20 clean), the full-flow stripped-id step-5 press divergence.

[thymikee]

Maintainer scope decision: keep #1269 focused on the measured non-unique id / get defect. The stripped-id fixture with verification still active proves that fix at equal sample size: 20/20 default divergences versus 20/20 clean after removing the non-selective id from both the selector chain and target-v1 identity.

The label-less clickable-container press failure is a separate class and should be tracked in a sibling issue rather than silently broadening this implementation. Its evidence and likely remedy differ: the actionable node has only a non-selective container role, while useful identity lives on a labeled descendant.

For #1269 itself, the implementation contract remains:

• demote any capture-time non-unique id in both selector-chain construction and target-v1 identity;
• use capture-time uniqueness, not an Android namespace heuristic;
• amend ADR 0012's identity rule;
• include Android duplicated framework-id coverage and an iOS/RN duplicated-testID fixture.

Do not claim that #1269 fixes general Android list-flow replay. It fixes the duplicated-id class; the container-press class needs its own issue and acceptance evidence.