This PR is a test to see what works and what breaks with JetBrains
OpenJDK 11 as far as Xamarin.Android is concerned.

Changes: dotnet/java-interop@80b4667...c19794e
Changes: dotnet/android-tools@36d7fee...f473ff9

Java.Interop changes are for OpenJDK11 build support

It builds locally!  (If that actually means anything.)

(Unit tests untested.)

Make "global" `$(JavacSourceVersion)` and `$(JavacTargetVersion)`
MSBuild properties for great consistency!

Use a new `$(JavacTargetVersion)` value for `javac -target` instead of
reusing `$(JavacSourceVersion)`, because...why not?

Cleanup `build-tools/scripts/Jar.targets` to *not* change the behavior
depending on what the installed JDK is.  JDK 1.8 is now a *minimum* to
*build* xamarin-android...and probably to *run* any Java code that we
build.  (Maybe.)

Various fixes to allow dotnet/java-interop@6d7266dd9 to build.

Our build outputs still need to be runnable on machines using JDK 1.8.

Otherwise, things may break when using those `.jar` files:

	error AMM0000: java.lang.UnsupportedClassVersionError: com/xamarin/manifestmerger/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	error AMM0000: 	at java.lang.ClassLoader.defineClass1(Native Method)
	error AMM0000: 	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	error AMM0000: 	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	error AMM0000: 	at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
	error AMM0000: 	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	error AMM0000: 	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
	error AMM0000: 	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	error AMM0000: 	at java.security.AccessController.doPrivileged(Native Method)
	error AMM0000: 	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	error AMM0000: 	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	error AMM0000: 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
	error AMM0000: 	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	error AMM0000: 	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
	error AMM0000: Error: A JNI error has occurred, please check your installation and try again
	error AMM0000: Exception in thread "main"
	error AMM0000: java.lang.UnsupportedClassVersionError :  com/xamarin/manifestmerger/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

`dx` doesn't like OpenJDK 11 on Windows:

	  "C:\Users\dlab14\android-toolchain\sdk\build-tools\29.0.2\dx" --dex --no-strict --output="C:\A\vs2019xam00000H-1\_work\2\s\bin\Release\lib\xamarin.android\xbuild\Xamarin\Android\java_runtime.dex" "C:\A\vs2019xam00000H-1\_work\2\s\bin\Release\lib\xamarin.android\xbuild\Xamarin\Android\java_runtime.jar"

	##[debug]Processed: ##vso[task.logdetail id=dffb25d4-cb0b-4e58-94d2-4b9a4f215bed;parentid=;name=EXEC;type=Build;starttime=2020-04-19T01:21:10.0332656Z;state=InProgress;]
	##[error]EXEC(0,0): Error : No suitable Java found. In order to properly use the Android Developer
	##[debug]Processed: ##vso[task.logissue type=Error;sourcepath=EXEC;linenumber=0;columnnumber=0;code=;]No suitable Java found. In order to properly use the Android Developer
	##[debug]Processed: ##vso[task.logdetail id=dffb25d4-cb0b-4e58-94d2-4b9a4f215bed;parentid=;type=Build;result=Failed;finishtime=2020-04-19T01:21:10.0488457Z;progress=100;state=Completed;parentid=;name=;]
	EXEC : error : No suitable Java found. In order to properly use the Android Developer [C:\A\vs2019xam00000H-1\_work\2\s\src\java-runtime\java-runtime.csproj]
	  Tools, you need a suitable version of Java JDK installed on your system.
	  We recommend that you install the JDK version of JavaSE, available here:
	    http://www.oracle.com/technetwork/java/javase/downloads

	  If you already have Java installed, you can define the JAVA_HOME environment
	  variable in Control Panel / System / Avanced System Settings to point to the
	  JDK folder.

	  You can find the complete Android SDK requirements here:
	    http://developer.android.com/sdk/requirements.html

	##[error]src\java-runtime\java-runtime.targets(59,3): Error MSB3073: The command ""C:\Users\dlab14\android-toolchain\sdk\build-tools\29.0.2\dx" --dex --no-strict --output="C:\A\vs2019xam00000H-1\_work\2\s\bin\Release\lib\xamarin.android\xbuild\Xamarin\Android\java_runtime.dex" "C:\A\vs2019xam00000H-1\_work\2\s\bin\Release\lib\xamarin.android\xbuild\Xamarin\Android\java_runtime.jar"" exited with code -1.

Use `r8.jar` instead, to hopefully avoid the problem.

java-runtime.targets requires that r8.jar exist in order to run.

Remember commit 6601fbc?  Same deal, different file.

  "C:\Users\dlab14\android-toolchain\jdk\bin\java.exe" -classpath "C:\A\vs2019xam00000I-1\_work\2\s\bin\Release\lib\xamarin.android\xbuild\Xamarin\Android\r8.jar" com.android.tools.r8.D8 --release --no-desugaring --output "obj\Release\netcoreapp3.1\android-29\" "C:\A\vs2019xam00000I-1\_work\2\s\bin\Release\lib\xamarin.android\xbuild-frameworks\Microsoft.Android\netcoreapp3.1\mono.android.jar"
  Compilation failed with an internal error.
  java.nio.file.InvalidPathException: Illegal char <"> at index 36: obj\Release\netcoreapp3.1\android-29" C:\A\vs2019xam00000I-1\_work\2\s\bin\Release\lib\xamarin.android\xbuild-frameworks\Microsoft.Android\netcoreapp3.1\mono.android.jar
  	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
  	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)

The `\"` in the command line cause the `"` to be "escaped", resulting
in an invalid command line on Windows.

Let's `.TrimEnd('\')` to avoid the escaping.

Right now the test phases are using:

    JavaSdkDirectory = C:\Program Files\Android\jdk\microsoft_dist_openjdk_1.8.0.25
    JavaSdkDirectory = /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home

So we aren't actually *testing* OpenJDK 11.

We are setting `$JAVA_HOME` when running the macOS build phase, let's
see if the exact same trick will work for running MSBuild tests.

To set `$JAVA_HOME` on each platform, I used:

* `$HOME/Library/Android/jdk` for macOS
* `%USERPROFILE%\android-toolchain\jdk` for Windows

…nto jetbrains-openjdk

Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3711144&view=logs&jobId=4348ab7c-72f0-52b0-44fd-6f17a16a558f&j=8556562a-ae5f-5bd1-7c4d-bf1af4b6f1e1&t=9f016295-34d3-5b55-55cb-51df877e2cc6

Usage of `avdmanager` fails under JDK 11:

  TestApks.targets(45,5): error : Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
  TestApks.targets(45,5): error : 	at com.android.repository.api.SchemaModule$SchemaModuleVersion.<init>(SchemaModule.java:156)
  TestApks.targets(45,5): error : 	at com.android.repository.api.SchemaModule.<init>(SchemaModule.java:75)
  TestApks.targets(45,5): error : 	at com.android.sdklib.repository.AndroidSdkHandler.<clinit>(AndroidSdkHandler.java:81)
  TestApks.targets(45,5): error : 	at com.android.sdklib.tool.AvdManagerCli.run(AvdManagerCli.java:213)
  TestApks.targets(45,5): error : 	at com.android.sdklib.tool.AvdManagerCli.main(AvdManagerCli.java:200)
  TestApks.targets(45,5): error : Caused by: java.lang.ClassNotFoundException: javax.xml.bind.annotation.XmlSchema
  TestApks.targets(45,5): error : 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
  TestApks.targets(45,5): error : 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
  TestApks.targets(45,5): error : 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
  TestApks.targets(45,5): error : 	... 5 more
  TestApks.targets(45,5): error : Process `/Users/runner/Library/Android/sdk/tools/bin/avdmanager` exited with value 1.

This is because the "normal" `tools`' `avdmanager` doesn't support
JDK 11, and has been replaced with a *new* `commandlinetools` package
whicih *does* support JDK 11.

Begin installing the `commandlinetools` SDK package, and use it for
`sdkmanager` invocations.

Context: xamarin/monodroid#1091

Try to fix the `Xamarin.Android.Tools.AndroidSdk.dll` which is
included into the installers, so that the xamarin-android-tools
submodule specified in xamarin-android is the one included.

Commit 79a417a worked, in that we no longer get XA5300 errors about
the JDK in use.

Yay

Things still fail, though:

	Task "Javac" (TaskId:154)
	  Task Parameter:JavaPlatformJarPath=/Users/runner/Library/Android/sdk/platforms/android-29/android.jar (TaskId:154)
	  Task Parameter:ClassesOutputDirectory=obj/Release/android/bin/classes/ (TaskId:154)
	  Task Parameter:ClassesZip=obj/Release/android/bin/classes.zip (TaskId:154)
	  Task Parameter:StubSourceDirectory=obj/Release/android/src/ (TaskId:154)
	  Task Parameter:ToolPath=/Users/runner/Library/Android/jdk/bin (TaskId:154)
	  Task Parameter:
	      Jars=
	          /Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v10.0/mono.android.jar
	          /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/java_runtime.jar (TaskId:154)
	  /Users/runner/Library/Android/jdk/bin/javac -J-Dfile.encoding=UTF8 "@/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmp2eba46d8.tmp"  (TaskId:154)
	JAVAC : error : option --boot-class-path not allowed with target 11 [/Users/runner/runners/2.168.2/work/1/s/bin/TestRelease/temp/ProguardBOMError/UnnamedProject.csproj]
	  The command exited with code 2. (TaskId:154)

JDK11 doesn't like `javac --boot-class-path` *unless* `javac -source`
and `javac -target` are used, specifying a version less than 9.

Provide default values for `$(JavacSourceVersion)` and
`$(JavacTargetVersion)` in `Xamarin.Android.Common.props`, so that we
tell `javac` that we're targeting JDK 8.

Currently `xamarin-android-tools` prefers a `C:\Program Files\Android\jdk` over `%JAVA_HOME%`:

https://github.com/xamarin/xamarin-android-tools/blob/f5fcb9fd1583ebe928734e8525303a0dbe93c79c/src/Xamarin.Android.Tools.AndroidSdk/Sdks/AndroidSdkWindows.cs#L137-L141

Before the test run, I made it move the Microsoft OpenJDK and restore it *after* the test run.

We need to restore it, otherwise we could break other builds running against master right now.

and write `package.xml` ourselves.

Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3729696&view=ms.vss-test-web.build-test-results-tab&runId=13228096&resultId=100066&paneView=attachments

Current failures?  `<CreateMultiDexMainDexClassList/>` is unhappy.
More precisely, JDK11 `java` is unhappy:

	$ /Users/runner/Library/Android/jdk/bin/java \
		-Djava.ext.dirs=/Users/runner/Library/Android/sdk/build-tools/29.0.2/lib \
		com.android.multidex.MainDexListBuilder …
	-Djava.ext.dirs=/Users/runner/Library/Android/sdk/build-tools/29.0.2/lib is not supported.  Use -classpath instead.
	CREATEMULTIDEXMAINDEXCLASSLIST : error : Could not create the Java Virtual Machine.
	CREATEMULTIDEXMAINDEXCLASSLIST : error : A fatal exception has occurred. Program will exit.
	The command exited with code 1.

JDK11 `java` no longer supports `-Djava.ext.dirs`.

Update `<CreateMultiDexMainDexClassList/>` so that it constructs a
`java -classpath` value and uses that.

Update `$(AndroidSdkBuildToolsVersion)` to 30.0.0-rc4

TODO: Is the `java -classpath` quoting correct?

TODO: So about the `$(AndroidSdkBuildToolsVersion)` semantics: should
it be in any way correlated with the JDK version in use?

If so, *how*?

We *know* that if `$(AndroidSdkBuildToolsVersion)` is >= 30, we need
JDK11.  How can we check that?

If `$(AndroidSdkBuildToolsVersion)` is < 30, does the JDK matter?
Given that all current failures are because of `java -Djava.ext.dirs`,
it migiht not matter, i.e JDK 11 works with 29.0.2.

Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3730828&view=logs&j=96fd57f5-f69e-53c7-3d47-f67e6cf9b93e&t=65256bb7-a34c-5353-bc4d-c02ee25dc133

"Funny" interaction with `$(LatestSupportedJavaVersion)` and
legacy `<ValidateJavaVersion/>` and `$(AndroidSdkBuildToolsVersion)`:
if `$(AndroidSdkBuildToolsVersion)` is not parseable by
`Version.TryParse()` -- which it isn't, right now, as it is
`30.0.0-rc4`, and the `-rc4` bit breaks parsing -- then we got an
XA0032 error that JDK 11.99.99 needed to be installed, because the
"latest supported version" becomes the "minimum required version".

...and here I was thinking that `$(LatestSupportedJavaVersion)` could
be an "upper bound" for a version that may not yet exist.

Additionally, setting `$(LatestSupportedJavaVersion)`=11.0.0 *also*
fails:

	error XA0030: Building with JDK version `11.0.4` is not supported. Please install JDK version `11.0.0`.

Immediate fix is to set `$(LatestSupportedJavaVersion)`=11.0.4 so that
the version we installed matches the "minimum required".

I'm not sure what a *good*, reliable, solution is.

Import `Configuration.props` so that projects use the JDK that
xamarin-android provisions.

…ngTest()

Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3731956&view=logs&j=afdd9f9c-cb6d-5c16-f94b-26085e0125c9&t=5e51d11f-7930-51de-e1cf-8c513d38b843

Wrong expected build-tools version.

Update the tests to read `Xamarin.Android.Common.props.in` so that it expects
what's in the repo.

`lint` is *also* in the new cmdline-tools package.

Update things to look for it there.

Add a new `$(AndroidCommandLineToolsVersion)` property.

Context: https://developer.android.com/preview/features#signature-scheme-v4
Contxt: https://developer.android.com/preview/features#incremental

`apksigner` from `build-tools` 30 creates a new `.idsig` file next to
the `.apk`. This is to enable a new `adb install --incremental`
feature.

We need to add this file to `@(FileWrites)` in the
`_CollectMonoAndroidOutputs` MSBuild target. This target doesn't check
if any of the files exist, so I think we can just always add to this
item group.

This makes the behavior match what we are doing for `$(AndroidSdkDirectory)` and `$(AndroidNdkDirectory)`.

This reverts commit 4eb11e8.

…nto jetbrains-openjdk

The previous code was somehow setting:

    JAVA_HOME = C:\Users\dlab14\android-toolchain\jdk"

We think there is some bug with yaml behavior here, since the actual code looked correct.

* I removed both quotes
* I put the script in a block, otherwise the ## characters were yaml comments

`Restore` was failing with:

    error XA0032: Java SDK 11.0.4 or above is required when using Android SDK Build-Tools 30.0.0-rc4.

This target only runs during `Restore` when
`$(AndroidUseLatestPlatformSdk)` is `true`, so we should just stop
using this "deprecated" MSBuild property.

This standardizes how we set `$(TargetFrameworkVersion)` across
several test projects.

Several projects were doing this, but also set
`$(AndroidUseLatestPlatformSdk)`, which could just be removed.

These `Condition` didn't match the `<Import/>` within the same file.

Context: a648981
Context: #4567
Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3745247&view=logs&j=43d78dc4-ec1e-5245-95fd-87585dd83b08&t=6c172c00-c01b-5149-b118-044152099deb

Ever since a648981, API-21 has been the minimum supported API-level
for applications, which in turn means that the minimum
`$(TargetFrameworkVersion)` value is v5.0.

What happens if an `.csproj` file doesn't explicitly provide a
`$(TargetFrameworkVersion)` value?  Then the project "inherits" the
default value specified in e.g. `Xamarin.Android.CSharp.targets`:

	<TargetFrameworkVersion Condition="'$(TargetFrameworkVersion)' == ''">v4.4</TargetFrameworkVersion>

v4.4 is API-19, which is less than v5.0/API-21.

Which means if a `.csproj` doesn't explicitly provide a
`$(TargetFrameworkVersion)` value, it defaults to an *invalid* value,
and is promptly greeted with a build error:

	error XA0001: Unsupported or invalid $(TargetFrameworkVersion) value of 'v4.4'. Please update your Project Options.

This is the scenario that the `tests/CodeBehind` tests was
encountering:
`tests/CodeBehind/BuildTests/CodeBehindBuildTests.csproj` attempts to
import `Configuration.props` to use `$(AndroidFrameworkVersion)`
as the default value for `$(TargetFrameworkVersion)`, but when those
tests execute, they don't run from that directory.  Consequently,
`..\..\..\Configuration.props` *does not exist*:

	Project "../../../Configuration.props" was not imported by "…/bin/TestRelease/temp/CodeBehind/FailedBuildFew_ConflictingButton/Release/project/CodeBehindBuildTests.csproj" at (21,3), due to false condition; (Exists('..\..\..\Configuration.props')) was evaluated as (Exists('..\..\..\Configuration.props')).

which means `$(TargetFrameworkVersion)` isn't set, the default is
used, and as the default is wrong, things break.

Fix this scenario by properly updating the default
`$(TargetFrameworkVersion)` values within
`Xamarin.Android.Bindings.targets`, `Xamarin.Android.CSharp.targets`,
`Xamarin.Android.FSharp.targets`, and
`Xamarin.Android.VisualBasic.targets` so that `v5.0` is the new
default value.

Fix those silly FileNotFoundExceptions!

This reverts commit b2edbc9.

This reverts commit 167d7ee.

This reverts commit e120f20.

This is similar to what we currently do here:

https://github.com/xamarin/xamarin-android/blob/3c868e05466322393a8c4af300177742123b678b/tools/xabuild/XABuildPaths.cs#L276

Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3746882&view=ms.vss-test-web.build-test-results-tab&runId=13360870&resultId=100081&paneView=attachments

`BindingBuildTest.JavaSourceJar()` fails when using JDK 11:

	error XACLP7004: System.ArgumentException: Directory '…/bin/TestRelease/temp/JavaSourceJar/obj/Debug/javadocs/javasourcejartest-sources/' does not appear to be an android doc reference directory.

This in turn happens because `javadoc` fails entirely:

	Task "JavaDoc" (TaskId:35)
	  Task Parameter:ToolPath=/Users/runner/Library/Android/jdk/bin (TaskId:35)
	  Task Parameter:SourceDirectories=obj/Debug/javasources/javasourcejartest-sources (TaskId:35)
	  Task Parameter:DestinationDirectories=obj/Debug/javadocs/javasourcejartest-sources (TaskId:35)
	  Task Parameter:JavaPlatformJar=/Users/runner/Library/Android/sdk/platforms/android-29/android.jar (TaskId:35)
	  /Users/runner/Library/Android/jdk/bin/javadoc -d obj/Debug/javadocs/javasourcejartest-sources -sourcepath obj/Debug/javasources/javasourcejartest-sources -subpackages . -cp "/Users/runner/Library/Android/sdk/platforms/android-29/android.jar"  (TaskId:35)
	  Loading source files for package .... (TaskId:35)
	  Constructing Javadoc information... (TaskId:35)
	  /usr/local/opt/gradle/libexec/src/signing/org/gradle/plugins/signing/signatory/package-info.java:20: warning: a package-info.java file has already been seen for package org.gradle.plugins.signing.signatory (TaskId:35)
	  package org.gradle.plugins.signing.signatory; (TaskId:35)
	                                    ^ (TaskId:35)
	  …
	  100 errors (TaskId:35)

*Not only* does JDK 11's `javadoc` fail to build this project, it
takes *forever* to do so:

	Task Performance Summary:
	…
	    76195 ms  JavaDoc                                    1 calls

Over *76 seconds* to execute.  Compare to when JDK 8 is used:

	      654 ms  JavaDoc                                    1 calls

From less than a second to over 76 seconds, for 100 errors.  Ouch.

Doubly worse, when I run the JDK 11 `javadoc` locally, it *never*
finishes (within ~10 minutes, anyway, before I give up).

In the interest of expediency, *disable* `JavaSourceJar()` when the
local JDK is JDK 9 or later.  This should allow the tests pass, while
we turn our attention to the Windows issues.

This reverts commit fe50c6e.

The following import does not work when the tests run:

    <Import
        Condition="Exists('..\..\..\Configuration.props')"
        Project="..\..\..\Configuration.props"
    />

`CodeBehindBuildTests.csproj` is copied to a directory, where it would
need to use this path:

    ..\..\..\..\..\..\..\Configuration.props

But the first path is correct, for when the project is built in-place
in `Xamarin.Android-Tests.sln`.

This path is getting too long... I think it is simpler to set
`$(TargetFrameworkVersion)` in the test, as we can use
`builder.LatestTargetFrameworkVersion ()`.

…OutputPath)

Without this any assertion looking at files in `$(IntermediateOutputPath)` was failing on Windows.

For:
* `CodeBehindUnitTests`
* `EmbeddedDSOTests`

This reverts commit 850d812.

Changes: dotnet/android-tools@f5fcb9f...967c278

  * dotnet/android-tools@967c278: Delete NuGet.Config
  * dotnet/android-tools@2d3690e: [Xamarin.Android.Tools.AndroidSdk] Nullable Reference Type support (#84)
  * dotnet/android-tools@2020b20: [Xamarin.Android.Tools.AndroidSdk] Preview Build-Tools are Last (#85)

…4753)

Fixes: #4752
Context: https://developer.android.com/preview/privacy/foreground-service-types

In 6e55c22 we added a `ServiceAttribute.ForegroundServiceType`
property to support emitting the
`//service/@android:foregroundServiceType` XML attribute within
`AndroidManifest.xml`.  `//service/@android:foregroundServiceType`
supports multiple `|`-separated values, e.g.:

	<service …
	    android:foregroundServiceType="location|camera|microphone"
	/>

Unfortunately, the code in 6e55c22 only supported a single value, so
if you attempted to do e.g.:

	[Service (…,
	    ForegroundServiceType = ForegroundService.TypeDataSync | ForegroundService.TypeLocation)]
	partial class MyService : Service {
	}

you would get an error such as:

	…\Xamarin.Android.Common.targets(2004,3): error XAGJS7004: System.ArgumentException: Unsupported ForegroundServiceType value '9'.
	…\Xamarin.Android.Common.targets(2004,3): error XAGJS7004: Parameter name: value
	…\Xamarin.Android.Common.targets(2004,3): error XAGJS7004:    at Xamarin.Android.Manifest.ManifestDocumentElement`1.ToString(ForegroundService value)
	…

Make the `ForegroundService` enum a `[Flags]` enum, and update
`ManifestDocumentElement<T>.ToString(ForegroundService)` so that
`ForegroundService` is handled appropriately, allowing it to emit
`|`-separated values.

Additionally, add "preview" support for the `camera` and `microphone`
values which are added in API-R.

Note that we cannot use the enum values yet for API-R because
`Xamarin.Android.Build.Tasks.dll` is built against the stable version
of `Mono.Android.dll` (API-29), which does not have these values.

I also audited the rest of the enumerations used in
`ManifestDocumenetElements` to ensure no other values were added in
API-R.

Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3776574&view=ms.vss-test-web.build-test-results-tab&runId=13573624&resultId=100013&paneView=debug

The CodeBehindUnitTests fail to build:

	…/Xamarin.Android.Aapt2.targets(226,3): error XA0000: Unhandled exception: System.FormatException: Input string was not in a correct format.
	…/Xamarin.Android.Aapt2.targets(226,3): error XA0000:   at System.Number.ThrowOverflowOrFormatException (System.Boolean overflow, System.String overflowResourceKey)
	…/Xamarin.Android.Aapt2.targets(226,3): error XA0000:   at System.Number.ParseInt32 (System.ReadOnlySpan`1[T] value, System.Globalization.NumberStyles styles, System.Globalization.NumberFormatInfo info)
	…/Xamarin.Android.Aapt2.targets(226,3): error XA0000:   at System.Int32.Parse (System.String s)
	…/Xamarin.Android.Aapt2.targets(226,3): error XA0000:   at Xamarin.Android.Tasks.ManifestDocument.CalculateVersionCode (System.String currentAbi, System.String versionCodePattern, System.String versionCodeProperties)
	…/Xamarin.Android.Aapt2.targets(226,3): error XA0000:   at Xamarin.Android.Tasks.Aapt2Link.GenerateCommandLineCommands (System.String ManifestFile, System.String currentAbi, System.String currentResourceOutputFile)
	…/Xamarin.Android.Aapt2.targets(226,3): error XA0000:   at Xamarin.Android.Tasks.Aapt2Link.ProcessManifest (Microsoft.Build.Framework.ITaskItem manifestFile)

This happens because the CodeBehindUnitTests set
`//uses-sdk/@android:minSdkVersion` to `R`, which is a somewhat
reasonable thing to do to target a preview API level, but
`ManifestDocument.CalculateVersionCode()` does not like that, as it
implicitly requires that `//uses-sdk/@android:minSdkVersion` be
consumable by `int.Parse()`, which is *not* true for "R".

Fix `ManifestDocument.CalculateVersionCode()` so that it only uses
`//uses-sdk/@android:minSdkVersion` if it's parseable as an int.

…rsion

Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3778167&view=ms.vss-test-web.build-test-results-tab&runId=13587054&resultId=100129&paneView=debug
Context: fa8ac9e

`lint` was moved to the `cmdline-tools` package, and in the process
the value returned by `lint --version` was *lowered* (?!):

	% ~/android-toolchain/sdk/tools/bin/lint --version
	lint: version 26.1.1
	% ~/android-toolchain/sdk/cmdline-tools/1.0/bin/lint --version
	lint: version 3.6.0

3.6.0 is less than 26.1.1, and thus `lint --disable` values which need
to be used *aren't* used, which results in `lint` errors:

	MainActivity.java(27,13): error XA0103:  Overriding method should call super.onCreate [MissingSuperCall]

In the interest of expediency, assume that we're using the
cmdline-tools package if `ToolPath` contains `cmdline-tools`, in which
case we treat `lint` as newer than any previous version.

(This may be less than ideal.)

Context: https://issuetracker.google.com/issues/150189789

Update the "legacy" `<ValidateJavaVersion/>` task to require JDK11
when using Build-tools r30, because `apksigner.jar` in Build-tools
r30.0.0-rc4 requires JDK11 to execute.

For example, see [this build][0] for PR #4735, which fails because
JDK 1.8 is used with Build-tools r30's apksigner.jar:

	Task "AndroidApkSigner"
	  Task Parameter:ApkSignerJar=C:\Users\dlab14\android-toolchain\sdk\build-tools\30.0.0-rc4\lib\apksigner.jar
	  …
	  Task Parameter:ToolPath=C:\Program Files\Android\jdk\microsoft_dist_openjdk_1.8.0.25\bin
	  Task Parameter:ManifestFile=obj\Release\android\AndroidManifest.xml
	  C:\Program Files\Android\jdk\microsoft_dist_openjdk_1.8.0.25\bin\java.exe -jar C:\Users\dlab14\android-toolchain\sdk\build-tools\30.0.0-rc4\lib\apksigner.jar sign --ks "C:\Users\dlab14\AppData\Local\Xamarin\Mono for Android\debug.keystore" --ks-pass pass:android --ks-key-alias androiddebugkey --key-pass pass:android --min-sdk-version 21 --max-sdk-version 29  "C:\A\vs2019xam00000Y-1\_work\1\s\bin\TestRelease\temp\BuildAotApplication AndÜmläüts_x86_64_True_True\bin\Release\UnnamedProject.UnnamedProject-Signed.apk"
	  java.lang.UnsupportedClassVersionError: com/android/apksigner/ApkSignerTool has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	  at java.lang.ClassLoader.defineClass1(Native Method)
	  …
	…\Xamarin.Android.Common.targets(2559,2): error MSB6006: "java.exe" exited with code 1.

This was "implicitly" the case before commit a2b827e, because
`$(AndroidSdkBuildToolsVersion)` couldn't be parsed, and thus
`$(LatestSupportedJavaVersion)` was being checked for, which caused
all the Designer and Windows unit tests to fail.

Commit a2b827e fixed those failures, at the cost of allowing
`apksigner.jar` use with JDK 1.8, which isn't correct.

Fix the Build-tools + JDK version semantics within
`<ValidateJavaVersion/>`.  This will "re-break the world."

To attempt to address *some* of that breakage, update the macOS
Designer unit tests to export the `$(JavaSdkDirectory)` environment
variable.  This will hopefully cause the Designer build system to use
the JDK11 install that xamarin-android provisions, thus avoiding an
XA0032 build error.

[0]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3771781&view=ms.vss-test-web.build-test-results-tab&runId=13535824&resultId=100072&paneView=attachments

Adds support for a JI_JAVA_HOME env override

Does it build?

Partially revert 5dd172e.

The macOS + Android Designer integration tests are no longer *building*:

	/usr/local/bin/pwsh -NoLogo -NoProfile -NonInteractive -Command . '/Users/runner/runners/2.169.1/work/_temp/5bb6e004-db1c-41eb-9c62-55135ac0bd4e.ps1'
	fatal: not a git repository (or any of the parent directories): .git

Let's see if it's because I added the call to setup-test-environment.yaml.

See also: xamarin/xamarin-android-tools/master@13cc497a

We want JDK11 on the macOS+Designer integration tests.

To do so, we need to revertscommit 0b6ec48, as including
`setup-test-environment.yaml` "changes things."

Multiple repositories may now be checked out by certain jobs
(specifically designer test jobs) which are using the
`setup-test-environment.yaml` template.  As a result, the value of
$(System.DefaultWorkingDirectory) will change:

Single repo default checkout:
    $(System.DefaultWorkingDirectory) = $(Agent.BuildDirectory)/s/xamarin-android

Multi repo checkout:
    $(System.DefaultWorkingDirectory) = $(Agent.BuildDirectory)/s

These changes allow jobs which are checking out multiple repos to
provide a full path to the xa source checkout to this template.

REVERT BEFORE MERGING TO MASTER (plus appropriate bump)

Try to see if `JdkInfo` can properly detect & validate the Windows
OpenJDK 11 installation, thus avoiding the dreaded XA0032 error.

We want unit tests to use JI_JAVA_HOME, if set, so that they use JDK11
when also using Build-tools r30+, which also requires JDK11.

Update `setup-test-environment.yaml` so that macOS exports
`JI_JAVA_HOME` to `$HOME/android-toolchain/jdk`, which `xaprepare`
maintains.

`$(CommandLineToolsFolder)` & co. is needed for/from 85093ff,
and was accidentally removed as part of the merge.

Reset the branch of xamarin-android-tools back to master.

Commit 9b25904 should NOT have changed
`JI_JAVA_HOME` in `setup-test-environment.yaml`, as that breaks macOS
unit test execution, as we provision the JDK into `$HOME/Library/Android/jdk`.

Why is macOS+Designer failing again?  It should be using JDK11, for now,
yet apparently isn't?

No idea why; hoping that `nuget restore -Verbosity detailed` will help.

The Designer currently only supports JDK8, which is why commit c8ab455
installed *both* JDK 1.8 & JDK 11.

Revert `$(AndroidSdkBuildToolsVersion)` to 29.0.2 so that JDK 11 is no
longer required, and update the Designer builds to use JDK 1.8.
This should allow the Designer integration tests to pass.

Export JavaSdkDirectory to a directory which exists!

JDK 11 is apparently slower than JDK 1.8. :-(