Repository navigation
[Flaky test] InstallAndroidDependenciesTest (GoogleV2/Xamarin, CoreCLR) fails intermittently across PRs #11973
Description
Activity
- added a commit that references this issue
on Jul 6, 2026 Still failing after the retry mitigation (#11974) — the retry isn't actually engaging
New occurrence of
InstallAndroidDependenciesTest("GoogleV2", CoreCLR), after #11974 was merged (2026-07-06):- Build: dnceng-public build 1506492
- Case:
InstallAndroidDependenciesTest("GoogleV2", CoreCLR), Release - Duration:
[5 s],Found Time Elapsed 00:00:04.61
Failed InstallAndroidDependenciesTest("GoogleV2",CoreCLR) [5 s] Error Message: Xamarin.ProjectTools.FailedBuildException : Build failure: UnnamedProject.csproj Build log recorded at .../temp/InstallAndroidDependenciesTestGoogleV2CoreCLR/install-deps.log Stack Trace: at Xamarin.ProjectTools.Builder.BuildInternal(...) in Common/Builder.cs:line 417 at Xamarin.ProjectTools.ProjectBuilder.Build(...) in Common/ProjectBuilder.cs:line 134 at Xamarin.Android.Build.Tests.AndroidDependenciesTests.InstallAndroidDependenciesTest(...) in AndroidDependenciesTests.cs:line 82The 3× retry from #11974 is effectively a no-op
The retry loop calls the builder like this:
for (int attempt = 1; attempt <= maxInstallAttempts; attempt++) { // wipe + recreate sdkPath / jdkPath ... if (b.Build (proj, parameters: buildArgs.ToArray ())) { // AndroidDependenciesTests.cs:82 installSucceeded = true; break; } TestContext.WriteLine ($"InstallAndroidDependencies attempt {attempt} of {maxInstallAttempts} failed. ..."); if (attempt < maxInstallAttempts) Thread.Sleep (TimeSpan.FromSeconds (10)); }
But
ProjectBuildersetsThrowOnBuildFailure = truein its constructor (Common/ProjectBuilder.cs:34), andBuilderthrows on a failed build instead of returningfalse(Common/Builder.cs:414-417):if (!result && ThrowOnBuildFailure) { ... throw new FailedBuildException (message); }
InstallAndroidDependenciesTestnever setsThrowOnBuildFailure = false(it's only disabled in two other tests in the same file). So the first failed attempt throwsFailedBuildException, which propagates straight out of theforloop — attempts 2 and 3 never run.This build's log confirms it: a single build invocation,
~4.6 selapsed, total[5 s], and theFailedBuildExceptionstack trace above. A working retry would instead logInstallAndroidDependencies attempt 1 of 3 failed, sleep 10 s, and take >20 s across up to three attempts.Suggested fix
Make the retry actually catch failures, e.g. either:
- Set
b.ThrowOnBuildFailure = false;before the loop and keep theif (b.Build (...))return-value check (assert after the loop as today), or - Wrap
b.Build (...)intry { ... } catch (FailedBuildException) { ... }inside the loop.
The underlying network/download failure still needs to be characterized from the per-test
install-deps.logartifact, so this issue should stay open regardless — but the current mitigation won't help until the retry can survive a failed attempt.- linked a pull request that will close this issueEnable Android dependency install test retries #12059
on Jul 13, 2026 - added a commit that references this issue
on Jul 14, 2026 - locked and limited conversation to collaborators
on Aug 22, 2026
Affected test
Xamarin.Android.Build.Tests.AndroidDependenciesTests.InstallAndroidDependenciesTestBoth parameter combinations that exercise the network-dependent SDK/JDK install path have been observed failing intermittently across multiple, unrelated PRs:
InstallAndroidDependenciesTest("GoogleV2", CoreCLR)InstallAndroidDependenciesTest("Xamarin", CoreCLR)Description
These tests fail randomly (not tied to any specific code change) on the public
dnceng-publicdotnet-androidCI pipeline. TheInstallAndroidDependenciestarget downloads/installs the Android SDK and JDK from a manifest, so the test is inherently sensitive to network flakiness and manifest availability.The failures are short (2–4 s) and manifest as a generic build failure, e.g.:
Command that is run under the test:
Source
Notes / next steps
install-deps.logartifact, which is not surfaced in the test output above. Collecting that log from a failing run will confirm whether this is a transient download/network failure vs. a real regression.InstallAndroidDependenciesinvocation or marking the test with a known-flaky annotation.Tracking issue to correlate these intermittent failures across PRs.