fix: filter covered Android snapshot surfaces#675
Conversation
Size Report
Startup median (7 runs, lower is better):
Top changed chunks:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 710a4ca013
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| appendNonEmptyAttribute(xml, "package", node.getPackageName()); | ||
| appendNonEmptyAttribute(xml, "content-desc", node.getContentDescription()); | ||
| appendAttribute(xml, "visible-to-user", Boolean.toString(node.isVisibleToUser())); | ||
| appendAttribute(xml, "drawing-order", Integer.toString(node.getDrawingOrder())); |
There was a problem hiding this comment.
Guard getDrawingOrder on API 23
On Android 6/API 23 devices this helper can still be installed because the manifest/build scripts set minSdkVersion/MIN_SDK to 23, but AccessibilityNodeInfo.getDrawingOrder() is only available starting API 24 per the Android reference. In that supported environment, serializing the first node will throw NoSuchMethodError and the snapshot instrumentation fails instead of returning XML; gate this call on Build.VERSION.SDK_INT >= 24 or omit the attribute on API 23.
Useful? React with 👍 / 👎.
|
Summary
Filter covered same-window Android snapshot surfaces so agent-facing refs match the foreground UI.
Android
UiAutomationhelper snapshots can include navigation/view surfaces that are still attached in the same accessibility window even though they are covered by the current screen. Some nodes inside those covered surfaces can still reportvisible-to-user=true, so filtering only on that flag is not enough.This adds the helper
drawing-orderattribute and uses it in the host parser to suppress lower drawing-order sibling subtrees when a higher sibling geometrically covers them and contains agent-visible content. The filter is intentionally generic Android helper behavior, not a React Navigation-specific workaround. React Navigation exposed the issue through drawer + stack surfaces, but the invariant is the same for any same-window covered sibling tree.The helper now emits
drawing-orderonly on Android API 24+, whereAccessibilityNodeInfo.getDrawingOrder()exists. On API 23 the attribute is omitted and the host keeps the existing conservative behavior instead of risking a helper crash.The traversal was kept allocation-conscious: hidden subtree pruning compacts children in place, covered-sibling pruning runs bottom-up, and subtree agent-visible-content checks are memoized with a
WeakMapso large RN trees are not repeatedly rescanned. Equal drawing-order siblings and sub-90% overlaps are intentionally kept; tests document those conservative limits because there is no reliable full-coverage z-order signal in those cases.Also documents the helper XML attribute contract and accepts negative Android bounds from clipped/offscreen nodes.
Validation
tsc -p tsconfig.jsonvitest run src/platforms/android/__tests__/index.test.ts src/compat/maestro/__tests__/runtime-targets.test.ts src/utils/__tests__/selector-is-predicates.test.tsscripts/package-android-snapshot-helper.sh ... android-snapshot-helper/distStack Preload Flow:android-helper, 6 foreground refs, drawer leak labels[]git diff --check