[Tools] Wait for Android JDWP application readiness

[davidnguyen-tech]

Status

Discontinued on 2026-09-01. The product-compatible preview backport was
validated downstream, but three exact consumer campaigns (15165979,
15165980, and 15165981) ended at 0/3 because Android remained at the Java
debugger gate. The investigation has moved to managed-only debugging with
_AndroidAllowJavaDebugging=false and transient am set-debug-app without
-w. Java-debugging opt-in is no longer a required outcome, so this proposal
is closing unmerged.

Original proposal

Android can acknowledge a temporary JDWP connection before Debug.waitForDebugger() has advanced far enough for the application to continue reliably. Keeping the connection open for a fixed delay hides that race on newer runtimes and provides no protocol evidence that startup is ready.

This change extends the existing JDWP packet path to:

• request DDM HELO and FEAT;
• use the runtime-advertised support_boot_stages capability instead of assuming support from the API level;
• treat DEBG as a pre-gate state and wait for a sticky A_GO snapshot or STAG transition;
• retain the existing 1400 ms compatibility hold after a successful FEAT response that does not advertise boot stages; and
• enforce one 10-second bound across capability negotiation, stage waiting, and the legacy hold.

Protocol failures fail closed. Caller cancellation and readiness timeout close an in-flight stream read, preserve distinct OperationCanceledException and TimeoutException behavior, and leave forwarded-port cleanup unchanged.

• Useful description of why the change is necessary.
• Links to issues fixed
• Unit tests

The deterministic tests cover pre-gate DEBG, transition to A_GO, out-of-order STAG before a stale HELO snapshot, timeout with a non-cooperative read, caller cancellation, FEAT failure, and the legacy fallback. The focused suite passes 6/6.

[davidnguyen-tech]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[jonathanpeppers]

@davidnguyen-tech FYI, I was reviewing the history on this JDWP connection. It appears to have been a workaround added for Android Subsystem for Windows, which is now retired/end-of-life.

I want to just delete all this code in .NET 12, and didn't want to touch for 11 at this point unless there is a problem.

I believe this code path is actually only used in Visual Studio, so not if you do dotnet run or dotnet build -t:Run. Were you seeing a problem with this somewhere?

[davidnguyen-tech]

Closing for #12625