fix(android): give a session capture the session's share of the helper budget

Merged
OK
11d ago
+175-46

Summary

Fixes the slow reads on a continuously updating Android screen reported in tester-army/e2e#841.

A persistent helper capture waited at most 5 s on its socket (2 s UiAutomation connect wait plus 3 s overhead), while the one-shot fallback gets 30 s. The device-side timeout bounds only the connect, not the tree traversal. A React Native debug build repainting a list every second answers ~500 nodes in 3-12 s, so every such capture crossed 5 s and was treated as wedged: force-stop the helper, one-shot am instrument (10-15 s), restart the session on the next read. A 3 s capture became a 20-40 s step and occasionally pushed the one-shot past the 30 s adb timeout, which is the exact error in the report.

Changes

  • snapshot-helper-session-lifecycle.ts: a session capture gets the same share of the helper command budget a session start already gets (half of 30 s, never below the old 5 s). The native connect wait stays at 2 s, so session identity is unchanged and no live session restarts. resolveAndroidSnapshotHelperStartBudgetMs is renamed to resolveAndroidSnapshotHelperSessionBudgetMs since it now covers both.
  • snapshot-helper-session-protocol.ts: the socket waits the full session command budget instead of a deadline derived from the connect wait. The unused native timeout parameter is removed.
  • Tests: pin the production budgets (2 s connect, 15 s transport) and the capture staying on the session past the connect wait. A real-time variant of the capture test failed on the old code and passed on the fix; the committed version is deterministic to satisfy the slow-test gate.
  • examples/test-app: new ticker route (?rows=&intervalMs=) whose every row repaints on a timer, as a fixture for this class of screen.

Verification

  • pnpm vitest run packages/platform-android: 105 files, 850 tests pass
  • pnpm typecheck and oxlint pass
  • On a local emulator the session path still captures the ticker in ~20-40 ms per read

Not reproduced on-device: this emulator serves the ticker too fast to cross the 5 s cliff, so the thrash chain is proven by code reading and unit tests rather than a before/after capture trace.

Notes for the reporter

  • A per-call "skip settle" option is not needed; reads already wait at most 500 ms for idle.
  • The 2.4-3.5 s helper time itself is main-thread contention in the RN debug build on per-node accessibility IPC. That cost stays, but it no longer multiplies.