On the CI emulator the app window intermittently has has-window-focus=false, so Espresso's RootViewPicker (used by Intents.intended(), onView(...).check(), Espresso.pressBack(), focus-dependent clipboard reads) waits 10s for a focused root and times out. Evidence: one matrix run (#463's merge-queue check, E2E (35)) failed 8 unrelated Espresso tests simultaneously while 280+ pure-Compose tests passed — a shared-dependency, environmental flake, not per-test logic. It recurs after#454 despite the existing input keyevent 82 + animation-disable. Each occurrence fails the leg and burns a full retry (~9 min).
CI-level (preferred): make the emulator reliably give the launched activity window focus after boot — beyond keyevent 82: e.g. wm dismiss-keyguard, settings put to keep screen on, am focus nudges, or a post-boot readiness gate that waits for has-window-focus=true before the suite runs. This fixes the whole class in both e2e + e2e-preview.
Per-test seams: injectable launcher/back/clipboard seams for the 5, mirroring #467's UriHandler approach.
Priority P3 (recurring E2E flake; throughput drag via forced retries).
## Problem (root-caused via #467)
On the CI emulator the **app window intermittently has `has-window-focus=false`**, so Espresso's `RootViewPicker` (used by `Intents.intended()`, `onView(...).check()`, `Espresso.pressBack()`, focus-dependent clipboard reads) waits 10s for a focused root and times out. Evidence: one matrix run (#463's merge-queue check, `E2E (35)`) failed **8 unrelated Espresso tests simultaneously** while 280+ pure-Compose tests passed — a shared-dependency, environmental flake, not per-test logic. It recurs **after** #454 despite the existing `input keyevent 82` + animation-disable. Each occurrence fails the leg and burns a full retry (~9 min).
## Already mitigated (#467)
3 link-tap tests converted to a Compose `LocalUriHandler` seam (focus-immune): `AppPasswordSetupScreenTest` (×2), `OutlookImapNoticeScreenTest.tappingImapHelpLink`.
## Still flaky — no `UriHandler` seam (this ticket)
These use real system intents / Espresso APIs with no Compose seam:
- `AccountPickerScreenTest.tappingOutlook`
- `OutlookImapNoticeScreenTest.tappingSignIn` (AppAuth `hasComponent`)
- `BatteryOptimizationStepTest.batteryStep_takeMeThere` (Settings intent)
- `LicenseScreenTest.systemBack` (`Espresso.pressBack`)
- `ReportReviewScreenTest.tappingCopy` (focus-dependent clipboard)
## Fix options
1. **CI-level (preferred):** make the emulator reliably give the launched activity window focus after boot — beyond `keyevent 82`: e.g. `wm dismiss-keyguard`, `settings put` to keep screen on, `am` focus nudges, or a post-boot readiness gate that waits for `has-window-focus=true` before the suite runs. This fixes the whole class in both `e2e` + `e2e-preview`.
2. **Per-test seams:** injectable launcher/back/clipboard seams for the 5, mirroring #467's `UriHandler` approach.
Priority P3 (recurring E2E flake; throughput drag via forced retries).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem (root-caused via #467)
On the CI emulator the app window intermittently has
has-window-focus=false, so Espresso'sRootViewPicker(used byIntents.intended(),onView(...).check(),Espresso.pressBack(), focus-dependent clipboard reads) waits 10s for a focused root and times out. Evidence: one matrix run (#463's merge-queue check,E2E (35)) failed 8 unrelated Espresso tests simultaneously while 280+ pure-Compose tests passed — a shared-dependency, environmental flake, not per-test logic. It recurs after #454 despite the existinginput keyevent 82+ animation-disable. Each occurrence fails the leg and burns a full retry (~9 min).Already mitigated (#467)
3 link-tap tests converted to a Compose
LocalUriHandlerseam (focus-immune):AppPasswordSetupScreenTest(×2),OutlookImapNoticeScreenTest.tappingImapHelpLink.Still flaky — no
UriHandlerseam (this ticket)These use real system intents / Espresso APIs with no Compose seam:
AccountPickerScreenTest.tappingOutlookOutlookImapNoticeScreenTest.tappingSignIn(AppAuthhasComponent)BatteryOptimizationStepTest.batteryStep_takeMeThere(Settings intent)LicenseScreenTest.systemBack(Espresso.pressBack)ReportReviewScreenTest.tappingCopy(focus-dependent clipboard)Fix options
keyevent 82: e.g.wm dismiss-keyguard,settings putto keep screen on,amfocus nudges, or a post-boot readiness gate that waits forhas-window-focus=truebefore the suite runs. This fixes the whole class in bothe2e+e2e-preview.UriHandlerapproach.Priority P3 (recurring E2E flake; throughput drag via forced retries).