Wire Android cmdline-tools resolver API into maui CLI

[rmarinho]

What & why

Bumps Xamarin.Android.Tools.AndroidSdk 1.0.189-preview.58 → 99.61.4266-ci.main.2128 to pick up the new command-line tools resolver API, and actually consumes it in the maui CLI.

Changes

• SdkManager wrappers — FindCommandLineTools() and EnsureLatestCommandLineToolsAsync() over the upstream FindSdkManager() / EnsureLatestCommandLineToolsAsync().
• maui doctor — the SDK Manager check now surfaces the resolved cmdline-tools revision + path.
• New command — maui android sdk update-tools (--json / --dry-run, live progress) ensures cmdline-tools;latest.
• Provider API — EnsureLatestSdkToolsAsync added to IAndroidProvider / AndroidProvider (+ test fake).
• Tests — 6 new (SdkManager resolver + command-level); 757/757 green.

Notes / risks

• 99.61.4266-ci.main.2128 is a rolling main-channel CI build served only from the dotnet11-transport feed (transport feeds prune old builds; there is no Maestro subscription, so it's a manual pin). The prior .58 pin was also transport-only, so this isn't a new dependency class — but it's less stable than a preview-channel version. Kept as draft pending a decision on this pin.

Single commit, based directly on main. Local validation: Microsoft.Maui.Cli builds clean; Microsoft.Maui.Cli.UnitTests 757/757 pass.

[github-actions]

Expert Code Review — PR #403

Methodology: 2 independent reviewers with adversarial consensus (1 reviewer failed to complete — reduced coverage, no tiebreaker; in this mode only findings both reviewers agreed on are included, and split findings are discarded).

Findings: 4 posted as inline comments — 0 critical, 2 moderate, 2 minor. No crash-class or data-loss defects.

Inline findings (all 2/2 consensus):

• 🟡 Rolling transport-feed version pin — restore/repro fragility; PR description build number doesn't match the pinned build.
• 🟡 null revision reported as Status = "updated" in JSON — machine consumers mis-read "already up to date" as "updated".
• 🟢 Progress pct only lower-clamped — inconsistent with Math.Clamp elsewhere; indeterminate phases render as stuck 0%.
• 🟢 Empty/unconfigured targetPath → blank dry-run path / opaque ArgumentNullException.

Discarded (flagged by only one reviewer, no consensus tiebreaker available):

• 🔴 Proposed NRE on tool.Revision — the other reviewer verified the upstream Task<CommandLineTool> contract is non-null, so accessing .Revision is safe. Discarded.
• 🟡 SdkBootstrapPhase enum → string switch lacks compile-time safety (silent fallthrough on upstream rename).
• 🟡 SdkManager.EnsureLatestCommandLineToolsAsync doesn't call SyncPaths() like sibling methods.
• 🟢 FindCommandLineTools() name diverges from the underlying FindSdkManager() call.

CI status: pending (no checks reported yet at time of review).

Test coverage: Good — the PR adds 6 targeted tests (command wiring, JSON invocation, dry-run no-op, resolver path/revision, null-SDK-path, empty-path throw) and a fake-provider implementation. Not covered: the "already up to date" (null revision) output path and the JSON Status semantics noted above.

Generated by Expert Code Review · 2 independent reviewers with adversarial consensus

Generated by Expert Code Review (auto) for #403 · 323.6 AIC · ⌖ 18.2 AIC · ⊞ 12.3K · ◷

[github-actions]

Expert Code Review: 4 findings posted inline. See the summary comment for methodology and details. No crash-class or data-loss defects found.

Generated by Expert Code Review (auto) for #403 · 323.6 AIC · ⌖ 18.2 AIC · ⊞ 12.3K

[github-actions]

🟡 MODERATE · consensus 2/2

null revision is overloaded as an "already up to date" sentinel, but JSON still reports Status = "updated". When the tools are already current, EnsureLatestSdkToolsAsync returns null, yet the JSON result here hardcodes Status = "updated". Machine consumers (IDE extensions, CI scripts) checking status == "updated" will incorrectly conclude an update happened. The human-readable path handles this correctly ("Command-line tools are up to date"), so only the machine-readable output is misleading. More broadly, a null revision conflates "no change" with "revision string unavailable."

Recommendation:

Status = revision is null ? "up_to_date" : "updated",

Consider having the wrapper return an explicit updated/unchanged signal rather than inferring state from a nullable revision.

[github-actions]

🟡 MODERATE · consensus 2/2

Rolling preview pin from a transport feed. 99.61.4269-preview.2131 (and the matching SHA in eng/Version.Details.xml) comes from the dotnet11-transport feed, which prunes old CI builds. A restore that works today can later fail with "package not found," breaking CI and consumers, and there is no Maestro subscription managing the pin so it must be bumped manually. The PR description also references a different build (99.61.4266-ci.main.2128) than what actually landed — reconcile that so provenance is auditable.

Recommendation: Prefer a version that flows through a durable channel (Maestro/darc), or at minimum add a comment in Version.Details.xml flagging this as a manual transport pin to review on each bump.

[github-actions]

🟢 MINOR · consensus 2/2

Progress percentage is only lower-clamped. Math.Max(0, pct) floors at 0 but does not cap the upper bound, and it collapses indeterminate phases (e.g. a -1 sentinel during CheckingForUpdates) to a stuck 0% bar. The sibling TryParseInstallProgressLine in SdkManager.cs uses Math.Clamp(p, 0, 100) — this call site is inconsistent with that pattern.

Recommendation: Use Math.Clamp(pct, 0, 100), and consider routing negative/sentinel values to the indeterminate spinner path instead of flooring to 0.

[github-actions]

🟢 MINOR · consensus 2/2

Empty/unconfigured targetPath yields a poor error path. If both androidProvider.SdkPath and DefaultAndroidSdkPath resolve to an empty (non-null) string, the dry-run prints a blank path (...tools at: ) and the live path throws an opaque ArgumentNullException (surfaced generically via HandleCommandException). Neither AndroidProvider.EnsureLatestSdkToolsAsync nor the sibling InstallSdkToolsAsync guards early.

Recommendation: Guard for null/empty targetPath up front with an actionable message (e.g. "No Android SDK path configured; run maui android install"), for example via ArgumentException.ThrowIfNullOrWhiteSpace(targetPath) in the provider.