test(e2e): convert view bounds to screen coordinates

[TimeToBuildBob]

Problem

Master CI run 37450774307 failed in NativeWindowInsetsTest.syncToggleReceivesRealTap: all three injected taps landed at (281, 53), but the switch preference never changed. The run had no ANR and the activity was resumed and displayed, so this is the recurrent no-ANR input miss rather than a product regression from the README-only master commit.

tapViewCenter passes getGlobalVisibleRect() coordinates directly to UiDevice.click(). Those coordinates are relative to the root view, while UiDevice.click() expects physical screen coordinates. Because native windows are padded below the status bar, the tap was injected one status-bar height too high. The CI coordinates prove it: the switch's root-relative center was y=53, inside the physical status-bar band.

Fix

Translate the visible rect by the decor view's physical-screen location before injecting the tap. This keeps the test as a real input-pipeline regression test rather than replacing it with performClick().

Verification

• git diff --check passes.
• The local host lacks Java/Android SDK, so the instrumentation compile could not run locally; CI is the authoritative check.
• Source commit: 529f085.

Fixes master CI run https://github.com/ActivityWatch/aw-android/actions/runs/37450774307.

[greptile-apps]

Confidence Score: 5/5

[Low risk] Test helper adjusts coordinate conversion for UI automation.

This PR appears safe to merge.

Summary

Updates tapViewCenter to add the decor view’s screen position to the visible bounds before calling UiDevice.click().

• Keeps taps on the real input path.
• No actionable issues found.
• Android instrumentation tests were not run during this review.

_{Reviews (1) · Last reviewed commit: "test(e2e): convert view bounds to screen..."}

[TimeToBuildBob]

🤖 AI code review

The PR changes tapViewCenter in NativeWindowInsetsTest.kt to allocate rootLocation and read the decor view's location on screen. It offsets the rectangle returned by getGlobalVisibleRect() by that location before passing its center to UiDevice.click().

Safe to merge — no P0/P1 findings

Confidence 5/5

✅ No findings. The diff looks correct to me on this pass.

Files changed (1) — the diff as I read it

• mobile/src/androidTest/java/net/activitywatch/android/NativeWindowInsetsTest.kt — Adds decor-view screen-location lookup and offsets the visible bounds in tapViewCenter before injecting the tap.

_{Reviewed 529f08556474 · panel: codex:gpt-6.1-sol · subscription engine · 13s · about this reviewer}

_{Maintainer commands}

_{@TimeToBuildBob review (own line) — fresh review · @TimeToBuildBob fix — a worker acts on the findings. Once per comment; 👀 = received.}

[TimeToBuildBob]

Fixed master run 37450774307 in #320. The failing test was injecting all three taps at root-relative (281, 53) directly into the physical screen, i.e. one status-bar offset too high. The helper now translates the view rect by the decor view's screen location before UiDevice.click().

Verification on the exact fix head (529f085): full CI is green, including Test E2E (29); Greptile and Bob review are both 5/5 with no findings. Ready for merge.

[TimeToBuildBob]

CI-green and mergeable (Greptile 5/5) — waiting only on a maintainer click.

This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted.