You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up from a live investigation for #1256 (merged) — the "actionable SystemUI overlay preservation" question. Ran a fresh #1256-branch daemon (418fa7e5 + snapshot-helper) against emulator-5560 (Pixel API 36) with the test-app.
Finding 1 — the get-divergence capture is app-window-scoped; separate-window overlays aren't captured
Separate-window actionable overlays (volume dialog, expanded quick-settings) are NOT captured by the divergence at all. Verified airtight:
Volume dialog held up across the capture (background key-repeat; VolumeDialog window confirmed present) → divergence screen.refs = 20 app-content refs, zero volume/systemui nodes.
Quick-settings shade persistent (up before and after the replay) → divergence screen.refs = 0.
A plain snapshot at the same moments does capture them (26 systemui/volume nodes incl. a hittablevolume_new_ringer_active_icon_container).
So the divergence surfaces the app-under-test's window (+ its in-window decor like the status bar), not independent system overlay windows.
Finding 2 — the synthetic id in the unit test isn't the live id
The snapshot-chrome-android-statusbar test splices a synthetic volume_dialog_container / volume_dialog_slider. Live, the volume dialog is: volume_dialog_container (✓ matches), volume_dialog, volume_dialog_top_container, volume_ringer_and_drawer_container, volume_new_ringer_active_icon_container (hittable). There is novolume_dialog_slider id in the live tree.
Implication (not a regression)
The #1256 fix is correct — it stops passive status-bar chrome (which does overlay the app window) from leaking into divergence refs. But the unit test that asserts "a synthetic volume_dialog_* overlay survives the non-raw walk" is a valid filter-logic unit test, not evidence of a live integration path: live, such separate-window overlays never reach the filter (app-scoped capture), so "actionable SystemUI overlay survives in divergence refs" is moot for them.
Suggested
Reword the test's comment to state it exercises the filter in isolation, not a live capture path.
Fix the synthetic volume_dialog_slider id (use volume_new_ringer_active_icon_container or a real seekbar id), or drop the specific id claim.
Evidence JSONs archived under ~/.agent-device-bench/wave3/E4/.
Follow-up from a live investigation for #1256 (merged) — the "actionable SystemUI overlay preservation" question. Ran a fresh #1256-branch daemon (
418fa7e5+ snapshot-helper) againstemulator-5560(Pixel API 36) with the test-app.Finding 1 — the get-divergence capture is app-window-scoped; separate-window overlays aren't captured
--rawcapture is 77 app + 29com.android.systemuinodes (clock,battery,mobile_*,statusIcons,status_bar*— exactly the chrome leaf-ids fix: Android status/nav-bar systemui chrome leaks into non-raw captures (#1251) #1256 filters).VolumeDialogwindow confirmed present) → divergencescreen.refs= 20 app-content refs, zero volume/systemui nodes.screen.refs= 0.snapshotat the same moments does capture them (26 systemui/volume nodes incl. a hittablevolume_new_ringer_active_icon_container).So the divergence surfaces the app-under-test's window (+ its in-window decor like the status bar), not independent system overlay windows.
Finding 2 — the synthetic id in the unit test isn't the live id
The
snapshot-chrome-android-statusbartest splices a syntheticvolume_dialog_container/volume_dialog_slider. Live, the volume dialog is:volume_dialog_container(✓ matches),volume_dialog,volume_dialog_top_container,volume_ringer_and_drawer_container,volume_new_ringer_active_icon_container(hittable). There is novolume_dialog_sliderid in the live tree.Implication (not a regression)
The #1256 fix is correct — it stops passive status-bar chrome (which does overlay the app window) from leaking into divergence refs. But the unit test that asserts "a synthetic
volume_dialog_*overlay survives the non-raw walk" is a valid filter-logic unit test, not evidence of a live integration path: live, such separate-window overlays never reach the filter (app-scoped capture), so "actionable SystemUI overlay survives in divergence refs" is moot for them.Suggested
volume_dialog_sliderid (usevolume_new_ringer_active_icon_containeror a real seekbar id), or drop the specific id claim.Evidence JSONs archived under
~/.agent-device-bench/wave3/E4/.