Enable Android dependency install test retries

[Copilot]

InstallAndroidDependenciesTest retries transient SDK/JDK download failures, but ProjectBuilder throws on the first failed build, preventing later attempts.

• Retry behavior
  • Disable ThrowOnBuildFailure for this test’s builder.
  • Preserve the existing three-attempt loop, cleanup, delay, and final assertion.

b.CleanupAfterSuccessfulBuild = false;
b.ThrowOnBuildFailure = false;

[simonrozsival]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[Copilot]

Pull request overview

This PR fixes the retry behavior of InstallAndroidDependenciesTest by ensuring the test can observe build failures as false return values (instead of exceptions), allowing its existing retry loop to function as intended when SDK/JDK downloads fail transiently in CI.

Changes:

• Disable ProjectBuilder.ThrowOnBuildFailure for InstallAndroidDependenciesTest so the three-attempt retry loop can continue after a failed build.

Show a summary per file

File	Description
src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/AndroidDependenciesTests.cs	Sets ThrowOnBuildFailure = false so transient dependency install failures don’t abort the retry loop via exceptions.

Copilot's findings

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

[github-actions]

✅ LGTM

Verdict: ✅ LGTM — Clean, minimal, correct fix.

Summary

The one-line change (b.ThrowOnBuildFailure = false;) is exactly what the retry loop needs. Previously, ProjectBuilder.Build throws FailedBuildException on the first failed build (Builder.cs:414), which aborted the three-attempt loop before it could retry transient SDK/JDK download failures. Disabling ThrowOnBuildFailure lets b.Build(...) return false, so the loop's cleanup + delay + retry logic works as intended, and the final Assert.IsTrue (installSucceeded, ...) still fails the test if all attempts fail.

Issue counts: ❌ 0 · ⚠️ 0 · 💡 1

Verification

• ✅ Retry loop (lines 76–92) now functions correctly across all 3 attempts.
• ✅ Final assertion still enforces success.
• ✅ The final default-target build (line 121) remains guarded by Assert.IsTrue, so disabling throw-on-failure for the whole builder doesn't mask a real failure there.
• ✅ Change is scoped to a single test; no production code affected.

Positive callouts

• Good use of a clear code comment referencing the tracking issue (#11973).
• Cleanup-per-attempt (deleting/recreating sdkPath/jdkPath) correctly avoids partial-download contamination between retries.

Nice, focused change.

Generated by Android PR Reviewer for #12059 · 65.1 AIC · ⌖ 18.5 AIC · ⊞ 6.8K
_{Comment /review to run again}

[github-actions]

🤖 💡 Testing — This is the correct fix: without it, Builder.Build throws FailedBuildException on the first failed attempt (Builder.cs:414), so the retry loop below could never reach attempts 2–3. One thing to be aware of: this disables throwing for the entire builder, including the final default-target build at line 121. That's still safe because that build is guarded by Assert.IsTrue (b.Build (...), "build should have succeeded."), so a real failure there is still surfaced. No change needed — just confirming the behavior is intentional.

(Rule: Verify retry/error-handling semantics)

[jonathanpeppers]

We should re-enable the ignored test in main, if this is really the fix.