[Microsoft.Android.Run] Await app shutdown on Ctrl+C

[jonathanpeppers]

---

Pressing Ctrl+C during dotnet run could let Microsoft.Android.Run exit before its fire-and-forget adb shell am force-stop completed, leaving the application running on the device.

Move shutdown into the awaited run lifecycle. The Ctrl+C handler now only signals cancellation, while final cleanup waits for force-stop before returning the standard SIGINT exit code. The device integration test now requires the app to be stopped immediately when dotnet run exits instead of polling around the race.

Fixes #11264

• Useful description of why the change is necessary.
• Links to issues fixed
• Unit tests: strengthened DotNetRunCtrlC; Microsoft.Android.Run builds with 0 warnings and errors.

[Copilot]

Pull request overview

This PR fixes a race where Microsoft.Android.Run could exit on Ctrl+C before adb shell am force-stop completed, leaving the app running on the device. It moves shutdown into the awaited run lifecycle and tightens the device integration test to require the app to be stopped when dotnet run exits.

Changes:

• Await StopAppAsync() during the run lifecycle shutdown instead of fire-and-forget from the Ctrl+C handler.
• Standardize SIGINT exit code handling via a CtrlCExitCode constant and improve StopAppAsync() error reporting.
• Strengthen DotNetRunCtrlC device integration test to fail if cancellation is reported as an error and to require immediate app shutdown.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Microsoft.Android.Run/Program.cs	Moves Ctrl+C shutdown work into the awaited lifecycle and adjusts stop-app behavior/exit code handling.
tests/MSBuildDeviceIntegration/Tests/InstallAndRunTests.cs	Updates Ctrl+C test expectations to validate no cancellation error and immediate device app termination.

[jonathanpeppers]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[github-actions]

⚠️ Needs Changes — 0 errors, 1 warning, 1 suggestion.

The cleanup is now correctly awaited before exit, and the immediate device-state assertion is stronger. The awaited adb force-stop still needs a bounded shutdown path so an unresponsive adb cannot make Ctrl+C hang indefinitely; the regression test should also lock in exit code 130.

CI is still in progress; all completed checks currently pass.

Generated by Android PR Reviewer for #12318 · gpt56 · 160.9 AIC · ⌖ 10.1 AIC · ⊞ 25.3K
_{Comment /review to run again}

[jonathanpeppers]

@dalexsoto review

[dalexsoto]

Blocking on one cancellation cleanup regression in src/Microsoft.Android.Run/Program.cs (around lines 211-219 and 577-608). If SIGINT arrives while the app-liveness pidof command is running, cancellation bypasses logcat cleanup. Since the Ctrl+C handler no longer kills logcat, its adb process can survive after Microsoft.Android.Run exits. This was reproduced at the current head: force-stop completed and exit code 130 was returned, but logcat remained reparented to PID 1. Please make logcat cleanup unconditional (for example, lifecycle cleanup in finally) and cover cancellation while pidof is in flight.

[jonathanpeppers]

@dalexsoto Fixed in 53688aed6. WaitForAppExitAsync() now wraps the full PID/logcat polling lifecycle in try/finally, so cancellation during an in-flight pidof still kills and waits for the logcat process before unwinding. The Ctrl+C handler remains synchronous. The run tool builds cleanly; I did not add a timing-dependent device test because there is currently no deterministic seam for holding pidof in flight.

[dalexsoto]

Reviewed the current changes. The new try/finally closes the in-flight GetAppPidAsync() cleanup hole: logcat is always killed and awaited before unwinding, followed by bounded, awaited force-stop cleanup. No blocking issues found.