Wait for Android JDWP application readiness

[davidnguyen-tech]

Status

Discontinued on 2026-09-01. Three exact downstream product campaigns
(15165979, 15165980, and 15165981) ended at 0/3: the validated package
overlay did not release the application from Android's Java debugger gate.
The consumer investigation has moved to managed-only debugging with
_AndroidAllowJavaDebugging=false and transient am set-debug-app without
-w. No additional producer build or JDWP package is planned, and this PR is
closing unmerged. The validation below remains as historical provenance.

Description

Backports the JDWP application-readiness fix from #12589 to
release/11.0.1xx-preview7.

The existing bounded hold can end before ART reaches Debug.waitForDebugger().
When that happens, the temporary JDWP connection closes and the app can enter
the debugger gate afterward with no Java debugger attached.

This change queries DDM capabilities with HELO and FEAT, waits for the
runtime-advertised STAG boot-stage signal, treats A_GO as the sticky ready
state, and retains the existing 1.4-second fallback for runtimes that do not
advertise boot-stage support.

Changes

• Add bounded DDM packet parsing for HELO, FEAT, and asynchronous STAG.
• Wait for A_GO instead of treating the pre-gate DEBG stage as ready.
• Preserve cancellation, timeout, protocol-error, and legacy-fallback behavior.
• Add focused tests for ordering, cancellation, FEAT errors, and fallback.
• Pin the preview 7 Android tooling identity through the release-owned
  AndroidToolsVersion property in eng/Versions.props, consumed by
  AndroidTools.GitInfo.targets and the external Android tools version target.
  GitInfo remains the fallback when the release property is not defined.

Validation

• Focused JDWP readiness tests pass 6/6 through the established external test
  project.
• The Release Xamarin.AndroidTools build succeeds with zero warnings and zero
  errors without command-line assembly-version overrides.
• Public build 1576007
  uses merge commit 7557a9dbad6caf048e52c612504db292aa29a1f6.
• Published package:
  Microsoft.Android.Sdk.Windows.37.0.0-ci.pr.gh12611.0.nupkg
  • SHA-256: ee60d1803cac7dd9a2f8b51742ac2ee13d68def057649b18cdcba9c9dcfc660d
• Packaged tools/Xamarin.AndroidTools.dll
  • SHA-256: 47d867a5c5ee08d6eceee0982a4f6cd9f26ac67cc16a1983e4832860c9339aa2
  • Identity: Xamarin.AndroidTools, Version=99.61.4269.0
  • Public key token: 87f7c026dcad9390; strong-name verification passes.
  • References match the preview 7 product baseline: Mono.AndroidTools
99.61.4269.0, Xamarin.Android.Tools.AndroidSdk 99.61.4269.0,
    netstandard 2.0.0.0, and System.Memory 4.0.1.2.

Current CI state

Aggregate build 1576007 completed failed at
2026-09-01T06:59:30.3838212Z. Its source remained exact pull-request merge
7557a9dbad6caf048e52c612504db292aa29a1f6. The package producer, dedicated
Android Tools jobs on macOS and Windows, all eight Windows MSBuild shards, and
eleven of twelve macOS emulator shards passed.

Windows > Build & Smoke Test failed independently while copying
Xamarin.Android.Tools.AndroidSdk.dll into Java.Interop BootstrapTasks:
MSBuild reported MSB3027/MSB3021 because another MSBuild process held the
destination file. This file-lock failure is outside the version/identity output
validated in the published package.

MSBuild Emulator Tests > macOS > MSBuild+Emulator 6 also failed when
MarshalMethodsAppRuns(CoreCLR) did not emit XXX:OnStart done. The test only
installs and starts an app and watches logcat; it never enters the debugger
attach path changed here. Current main explicitly ignores this test as the
known CoreCLR marshal-methods issue #12206. These were the build's only two
failed job paths.

Testing

• Useful description of why the change is necessary.
• Links to the corresponding main-branch change ([Tools] Wait for Android JDWP application readiness #12589).
• Unit tests: focused JDWP readiness tests pass 6/6.
• Release build succeeds with zero warnings and zero errors.