[FastDeploy] Verify install with 'pm path' and diagnose disk space

[simonrozsival]

Summary

This PR makes Fast Deployment detect and recover from a silently-failed pm install, instead of misreporting it as an unsupported-device error many seconds later. It also adds diagnostics that reveal the most common underlying cause (a full /data partition on CI emulators).

The problem

Fast Deployment decides whether pm install succeeded by parsing adb's stdout, and AdbOutputParsing.CheckInstallSuccess treats empty output as success. In practice an install can report success (or return empty/garbled output) while the package never actually materializes on the device — most often because the emulator's data partition is nearly full, which pm install does not reliably report as INSTALL_FAILED_INSUFFICIENT_STORAGE.

When that happens, the tooling believes the app is installed and proceeds straight to its only post-install signal: the run-as <pkg> pwd probe. That probe fails with:

run-as: couldn't stat /data/user/N/<pkg>: No such file or directory

which is exactly the message emitted by the known install↔run-as materialization race (#7821 / #11808). The code therefore retries for ~4.5s and, when the package still isn't visible, gives up with:

XA0137 — "Fast Deployment is not currently supported on this device."

So a genuine install failure is masked as a device-capability problem, with no indication of the real cause. This showed up in a CI Package Tests > APKs Debug lane that compiled cleanly, ran zero tests, and died at deploy with the couldn't stat error — the classic signature of this masking.

The fix

1. Positively verify the install with pm path, and reinstall once if it's missing.

After a successful-looking InstallPackage, the task now confirms the package is really present by querying pm path <pkg> — the same technique AndroidDevice.WaitUntilReady already uses for pm path android:

• package:/… returned → the install genuinely landed. Any later run-as "couldn't stat" really is the materialization race, so the existing retry / XA0137 path stays in control and behavior is unchanged.
• Empty result → the install silently failed. The task forces a single reinstall (ReInstall = true → InstallPackage (installed: false)) before falling through to the run-as probe, giving deployment a real chance to succeed rather than timing out.

--user is honored when AndroidDeviceUserId is set. No new user-facing or localized strings are introduced: if the package is still missing after the reinstall, the existing run-as probe surfaces the failure just as before — now accompanied by diagnostics noting that a reinstall was already attempted.

2. Log free /data space when a package goes missing after install.

Because a vanishing package is so often a full-disk symptom, when pm path reports the package missing the task logs the device's free space on /data (via the existing AndroidDevice.GetAvailableSpace) and records a deploy.data.free.bytes diagnostic property. This is best-effort and never throws.

Taken together, empty pm path + low /data free space is strong evidence the failure is disk-space related (a candidate for ADB0060) even when pm never said so.

How it fits into the existing flow

The change is purely additive and gated to the post-install path:

1. InstallPackage runs as before.
2. New: IsPackageInstalled (pm path <pkg>) confirms the package exists.
3. New (only if missing): log disk space, set deploy.reinstall.after.missing.package, reinstall once, re-check.
4. Existing run-as probe / retry / XA0137 logic runs unchanged.

The happy path is identical apart from one extra pm path query.

Diagnostics added

• deploy.reinstall.after.missing.package — a reinstall was triggered because pm path found nothing.
• deploy.data.free.bytes — free bytes on /data at the moment the package was found missing.
• Log lines recording each pm path result and the free-space reading.

Testing

• Builds clean: Xamarin.Android.Build.Debugging.Tasks.
• Change is additive and confined to the post-install path; the happy path is unaffected aside from a single extra pm path query.

[Copilot]

Pull request overview

Improves Fast Deployment reliability by positively verifying that a post-pm install package actually exists on-device, and by emitting diagnostics that help distinguish genuine install failures (often disk-space related) from the known run-as data-dir materialization race.

Changes:

• After a “successful-looking” install, validate presence via pm path <pkg> and force a single reinstall if the package is missing.
• When the package is missing, log best-effort free /data space and record a deploy.data.free.bytes diagnostic property.

Show a summary per file

File	Description
src/Xamarin.Android.Build.Debugging.Tasks/Tasks/FastDeploy.cs	Adds pm path verification + one-time reinstall fallback and logs /data free space diagnostics when the package appears missing.

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 2