Bump to xamarin/xamarin-android-tools:master@917d3b3c

[jonpryor]

Context: https://paper.dropbox.com/doc/OpenJDK-and-You--AH1yWKdVXgno~uXYfmcUAZTwAg-NoECAe2XkBQeoxFfGL6ea
Context: dotnet/android-tools#29 (comment)
Context: #2004 (comment)
Context: https://github.com/xamarin/xamarin-android-tools/blob/917d3b3ce455eed6a4a0e4271d34661bdf0b261d/src/Xamarin.Android.Tools.AndroidSdk/JdkInfo.cs#L256

Fixes: http://work.devdiv.io/646086
Fixes: http://work.devdiv.io/652760
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/597752
Fixes: dotnet/android-tools#26
Fixes: dotnet/android-tools#39

Update & export %JAVA_HOME%, %PATH% on Windows.

We are observing some unit test failures in this bump, which
appear to be machine-specific. We still don't understand the
cause of the unit test failures, so to assist in the eventual tracking
of this issue there is some additional, conditional, debug spew.

[jonpryor]

dotnet/android-tools@07c4c2b fixed one failure, but there are still 4 failures left. :-(

[jonpryor]

If I'm very lucky, the CheckSignApk() failures are because the NDK couldn't be determined from $PATH, fixed in dotnet/android-tools@511d580.

However, that doesn't really make sense as we should always be explicitly providing the NDK location, so I doubt I'm that lucky.

In the meantime, update the assertions within CheckSignApk() so that I can at least know which assertion is failing.

[jonpryor]

@dellis1972 noted the problem: the warning that is causing the unit test failures is in the console output and build logs:

Xamarin.Android.Common.targets(691,2): warning : Not a valid JDK directory: `/var/folders/19/hjm21bn17913_0ck7nh3thdr0000gn/T/tmp731daee6.tmp/microsoft_dist_openjdk_1.8.999` [/Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/tests/TestRunner.NUnit/TestRunner.NUnit.csproj] [/Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/build-tools/scripts/RunTests.targets]

That explains why an assertion that no warnings are reported is failing.

What I don't understand is how this is happening: the path it's complaining about is a path within $TEMP, e.g. from this unit test:

https://github.com/xamarin/xamarin-android-tools/blob/917d3b3ce455eed6a4a0e4271d34661bdf0b261d/src/Xamarin.Android.Tools.AndroidSdk/Tests/AndroidSdkInfoTests.cs#L270

The problem is:

1. The "override path" is an AppDomain.SetData() value, and
2. This unit test isn't run.

I am thus having a problem understanding how this temporary path -- with a directory name matching what our unexecuted unit tests create -- is causing a problem here.

¯_(ツ)_/¯

[jonpryor]

macOS PR Build 3711 succeeded.

I am thus faced with the prospect that this is in fact a machine-specific failure, as it failed on xam-mac-mini-6, but passed on xam-mac-mini-7.

(insert crying here.)

[jonpryor]

The story so far...

To assist investigation, I created a new (to be deleted) xamarin-android-tools/jonp-dump-xa-pr-2004 branch, which changed JdkInfo.TryGetJdkInfo() to provide a "locator" in the warning message:

		static JdkInfo TryGetJdkInfo (string path, Action<TraceLevel, string> logger, string locator)
		{
			JdkInfo jdk = null;
			try {
				jdk = new JdkInfo (path, locator);
			}
			catch (Exception e) {
				logger (TraceLevel.Warning, $"Not a valid JDK directory: `{path}`; via locator: {locator}");
				logger (TraceLevel.Verbose, e.ToString ());
			}
			return jdk;
		}

(I should make a proper PR and merge this.)

The locator information lets us know where the path came from. After running on xam-mac-mini-7, it passed all unit tests, which was not unexpected. Rebuild on xam-mac-mini-6 (yay luck!), and it predictably failed, providing us the updated warning message:

warning : Not a valid JDK directory: `/var/folders/19/hjm21bn17913_0ck7nh3thdr0000gn/T/tmp731daee6.tmp/microsoft_dist_openjdk_1.8.999`; via locator: monodroid-config.xml

Success! We can now piece together what happened.

The original unit tests for AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() would backup the original monodroid-config.xml, implicitly create a new one, validate the contents of the new one, then restore the original file:

if (File.Exists (UnixConfigPath))
    File.Move (UnixConfigPath, backupConfig);
// ...
if (File.Exists (backupConfig))
    File.Move (backupConfig, UnixConfigPath)

However, this logic was faulty: File.Move() will not overwrite the target file if it already exists. As the target file already existed -- it was "implicitly" created by calling AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() -- the File.Move() threw an (unreported?!) exception, meaning from that point onward the monodroid-config.xml on that PR builder was wrong.

And this was on the xamarin-android-tools PR builder Job, not the xamarin-android PR builder Job, though they share the same machines.

This bug was later fixed, but the damage had already been done. (The fix was later made redundant by altering the unit tests so that they ever used the "system" location for these tests, which we arguably should have done in the first place.)

The fix? We need to connect to xam-mac-mini-6 and delete monodroid-config.xml/restore the previously backed up "good" version.

[jonpryor]

(I should make a proper PR and merge this.)

Which is here: dotnet/android-tools#43