[bitsandfoxes]

AdbProvider now 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 -W then didn't start a new process: it brought the hung activity back to the front, so pidof returned the same PID, the run waited out the full timeout again, and logcat --pid returned 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: 4056 for all five launches, 0 of 81 tests passed, 25 of the job's 30 minutes spent waiting).

How it works now:

• RunApplication runs am force-stop <package> before clearing logcat and launching, so every launch starts a fresh process. This matches what iOSSimulatorProvider (simctl terminate) and SauceLabsProvider (mobile: terminateApp) already do before a launch.
• After a run timeout, it reads the run's logs first and then force-stops the package, so the hung process doesn't outlive the run.
• A failing force-stop only 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-DeviceApp parameter 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.ps1 covers the order of commands on a normal run and on a timeout, and that a failing force-stop doesn't block the launch, with InvokeCommand faked (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