Repository navigation
fix(adb): Force-stop the app before each launch and after a run timeout - #64
Merged
Merged
Conversation
bitsandfoxes
marked this pull request as ready for review
October 29, 2026 10:20
bitsandfoxes
requested review from
a team,
jpnurmi,
limbonaut and
tustanivsky
October 29, 2026 10:21
BootSimulator cleared FreshlyBooted before simctl boot, so a second boot of a simulator this provider just booted (Connect, then Start-Device) hit the already-Booted early return with the flag lost, and the first launch ran the simctl terminate the fresh-boot skip exists to avoid. Clear it only once the boot command has run.
The test got there by having the fake boot throw 'Unable to boot device in current state: Booted', but the real InvokeBuiltCommand throws an exit-code message, so production reaches an already-booted simulator through SelectAndConnect's booted branch. Connect by UUID to a simulator the fake lists as Booted instead, so that branch is covered.
BootSimulator matched simctl's 'Unable to boot device in current state: Booted' text, but InvokeBuiltCommand throws only 'Command (boot) failed with exit code N', so a second boot of a simulator this provider booted rethrew instead of keeping FreshlyBooted. Ask for the simulator state when boot fails and rethrow the boot error unless it is Booted, and have the test fake throw the exit-code message the real command throws.
Matches the helper name SauceLabsProvider uses for the same job (and the 'terminate' wording iOS Simulator uses), so searching for how providers reset the app before a run finds Adb too. The 'force-stop' command key and warning text stay, since they name the adb verb.
bitsandfoxes
force-pushed
the
fix/adb-hung-launch
branch
from
October 29, 2026 11:07
bbca078 to
636c432
Compare
JoshuaMoelans
approved these changes
Oct 29, 2026
tustanivsky
approved these changes
Oct 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AdbProvidernow force-stops the package before it launches it, and again after a run that didn't exit within the run timeout.Until now, a run that hung left its process alive, and the provider only printed a warning. The next
am start -Wthen didn't start a new process: it brought the hung activity back to the front, sopidofreturned the same PID, the run waited out the full timeout again, andlogcat --pidreturned next to nothing. One hung launch failed every launch after it. In sentry-unity's Android integration tests, 7 jobs in the last 30 days went this way (e.g. 118708786184:App PID: 4056for all five launches, 0 of 81 tests passed, 25 of the job's 30 minutes spent waiting).How it works now:
RunApplicationrunsam force-stop <package>before clearing logcat and launching, so every launch starts a fresh process. This matches whatiOSSimulatorProvider(simctl terminate) andSauceLabsProvider(mobile: terminateApp) already do before a launch.force-stoponly logs a warning; the launch goes ahead as before.I left out an early "the app logged nothing yet" timeout: the provider has no app-agnostic readiness signal (what an app logs first is up to the engine), and adding one means a new
Invoke-DeviceAppparameter for every provider plus logcat polling in the monitor loop. Callers that know their app can detect a launch that never initialised from the returned output and relaunch it, which sentry-unity does in getsentry/sentry-unity#2901.Tests:
AdbRunApplication.Tests.ps1covers the order of commands on a normal run and on a timeout, and that a failing force-stop doesn't block the launch, withInvokeCommandfaked (no device needed).Stacked on #63.
CI evidence: run 40185846696, with a throwaway commit (since dropped) that made the first launch wait for a debugger, so it never initialised. In all 4 Run Android jobs, the first launch (Message Capture) waited out the timeout, then logged
::warning::Android app never initialised, relaunching (1/1). The relaunch came up under a new PID (e.g. 121151142372:4326→6421) and each job passed 77/77 (4 skipped).🤖 Generated with Claude Code