Changes: dotnet/runtime@62304a6...fd8f5b5
Changes: dotnet/emsdk@9a29abd...08a90ca

Updates:

* Microsoft.NET.ILLink: from 8.0.3-servicing.24114.15 to 8.0.4-servicing.24168.9
* Microsoft.NET.ILLink.Tasks: from 8.0.3 to 8.0.4
* Microsoft.NETCore.App.Ref: from 8.0.3 to 8.0.4
* Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100: from 8.0.3 to 8.0.4

Changes: dotnet/installer@412bfd7...5b9983e

Updates: Microsoft.Dotnet.Sdk.Internal: from 8.0.202-servicing.24116.2 to 8.0.204-servicing.24169.39

Other changes:

* Feeds for dotnet/runtime 6.0.29

* Feeds for dotnet/runtime 7.0.18

Co-authored-by: Jonathan Peppers <[email protected]>

Changes: https://github.com/xamarin/monodroid/compare/7edfb4a9...d627218f

* xamarin/monodroid@d627218f1: Bump to xamarin/android-sdk-installer/release/8.0.1xx@a6a2702a (xamarin/monodroid#1453)

Update the `InstallAndroidDependencies` target to use the
`ANDROID_HOME` environment variable by default, if set:

	% export ANDROID_HOME=path/to/android/sdk
	% dotnet build -t:InstallAndroidDependencies -f:net8.0-android \
	  -p:JavaSdkDirectory="<JavaSdkPath>" \
	  -p:AcceptAndroidSDKLicenses=True
	# provisions the Android SDK at $ANDROID_HOME

Context: https://aka.ms/1espt

The build pipeline has been updated to extend the 1ES pipeline template,
which will keep the pipeline up to date with the latest compliance and
security requirements.  Most compliance tasks and scans will now run
automatically as part of artifact upload steps.  API Scan and policheck
scans against multiple languages are not supported and will continue to
run separately.

The `NuGetAuthenticate@0` task is deprecated and will soon be removed:

    Task 'NuGet authenticate' version 0 (NuGetAuthenticate@0) is deprecated.
    This task will be removed. From January 31, 2024, onwards it may no longer be available.

Use the updated `NuGetAuthenticate@1` task instead.

Context: https://dotnet.microsoft.com/platform/support/policy/xamarin
Context: ab3773c

Support for Xamarin.Android ends on 2024-May-1.

Update error and warning messages to minimize use of "Xamarin".

Remaining messages which contain "xamarin" are:

  * XA0030: Building with JDK version `{0}` is not supported.
    Please install JDK version `{1}`.
    See https://aka.ms/xamarin/jdk9-errors

  * XA1005: If basic type name matching fails, please add a
    `xamarin:managedType` attribute to the element to specify the fully
    qualified managed type name of the element

XA0030 Should Not Happen with .NET 6+, as JDK 11+ is required.
XA0030 is thus moot.

XA1005 is related to Layout Code Behind (ab3773c), and replacing
`xamarin` would (1) be a source breaking change (so we can't *remove*
support for `xamarin`), and (2) while we could add an alternate XML
namespace to use for layout code behind, that's a larger change.

Changes: dotnet/android-tools@d3e7284...d50747c

  * dotnet/android-tools@d50747c: Check for ANDROID_HOME Sdk location on Windows. (dotnet/android-tools#230)

The `@self` yaml template annotation only appears to be needed in the
pipeline file, and not in nested templates.  This should fix potential
issues with other repos that use these templates.

…8904)

Fixes: dotnet/maui#18819

Context: https://github.com/kernshen/NoJavaPeer.git
Context: #4225 (comment)

An assembly's assembly references do not include transitive
dependencies.  Given:

	// Mono.Android.dll
	namespace Java.Lang {
	    public partial class Object {}
	}

	// MauiLib1.dll
	namespace MauiLib1 {
	    public class BaseClass : Java.Lang.Object {}
	}

	// MauiLib2.dll
	namespace MauiLib2 {
	    public class DerivedClass3 : MauiLib1.BaseClass {}
	}

then the assembly references for `MauiLib1.dll` will include
`Mono.Android.dll` (it directly references a type from it),
while the assembly references for `MauiLib2.dll` will include
`MauiLib1.dll` (it directly references a type from it) *but*
`MauiLib2.dll` *will not* have an assembly reference to
`Mono.Android.dll`.

This is how things have worked since .NET Framework 1.0.  This should
not be surprising.

[As part of the .NET for Android][0] [`SignAndroidPackage`][1] target,
Java Callable Wrappers (JCWs) need to be emitted for all
`Java.Lang.Object` subclasses.  This in turn requires
*loading all assemblies* to *find* the `Java.Lang.Object` subclasses.
As a performance optimization, we only load assemblies which we
believed could contain `Java.Lang.Object` subclasses:

 1. Assemblies with `'%(TargetFrameworkIdentifier)' == 'MonoAndroid'`,
    which is "carry over" from how Xamarin.Android did things,
    and works if a .NET for Android project references a
    Xamarin.Android project.

 2. Assemblies with an assembly reference to `Mono.Android.dll`.

Assemblies with transitive dependencies were caught by (1)…
in Xamarin.Android.

With .NET for Android, that is no longer the case:
`%(TargetFrameworkIdentifier)` is now always `.NETCoreApp`.  This in
turn meant that the only assemblies that could be used to generate
JCWs were those which directly referenced `Mono.Android.dll`!

Enter dotnet/maui#18819 and kernshen/NoJavaPeer, which contains
MAUI and .NET for Android solutions with the above transitive reference
structure:

 1. `MauiLib1.dll` / `AndroidLib1.dll` references `Mono.Android.dll`,
    exports `BaseClass`

 2. `MauiLib2.dll` / `AndroidLib2.dll` references `*Lib1.dll` *and not*
    `Mono.Android.dll`; exports `DerivedClass3` which inherits `BaseClass`.

 3. App project attempts to instantiate `DerivedClass3`.

The result: a runtime exception:

	Only System.NotSupportedException Message=Cannot create instance of type 'MauiLib2.DerivedClass3': no Java peer type found.
	   at Java.Interop.JniPeerMembers.JniInstanceMethods..ctor(Type declaringType) in /Users/runner/work/1/s/xamarin-android/external/Java.Interop/src/Java.Interop/Java.Interop/JniPeerMembers.JniInstanceMethods.cs:line 22
	   at Java.Interop.JniPeerMembers.JniInstanceMethods.GetConstructorsForType(Type declaringType) in /Users/runner/work/1/s/xamarin-android/external/Java.Interop/src/Java.Interop/Java.Interop/JniPeerMembers.JniInstanceMethods.cs:line 77
	   at Java.Interop.JniPeerMembers.JniInstanceMethods.StartCreateInstance(String constructorSignature, Type declaringType, JniArgumentValue* parameters) in /Users/runner/work/1/s/xamarin-android/external/Java.Interop/src/Java.Interop/Java.Interop/JniPeerMembers.JniInstanceMethods.cs:line 139
	   at Java.Lang.Object..ctor() in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/obj/Release/net8.0/android-34/mcw/Java.Lang.Object.cs:line 37
	   at MauiLib1.BaseClass..ctor()
	   at MauiLib2.DerivedClass..ctor() in C:\Project\Maui\MauiApp1\MauiLib2\Platforms\Android\DerivedClass.cs:line 7
	   at MauiApp1.App..ctor(IServiceProvider serviceProvider) in C:\Project\Maui\MauiApp1\MauiApp1\App.xaml.cs:line 18

The exception occurs because there is no JCW for `DerivedClass3`, and
there isn't a JCW for `DerivedClass3` because `MauiLib2.dll` was not
processed at all, because it had no assembly reference to
`Mono.Android.dll`.

As a workaround, update `MauiLib2.dll` to contain an assembly reference
to `Mono.Android.dll`.

*Fix* this scenario by updating
`MonoAndroidHelper.IsMonoAndroidAssembly()` to consider these to be
.NET for Android assemblies:

 1. Assemblies with `%(TargetFrameworkIdentifier)` *containing*
   `Android`.  (This doesn't actually change anything; it's a
    simplification.)

 2. Assemblies with `%(TargetPlatformIdentifier)` *containing*
    `Android`.

    *This* causes `MauiLib2.dll` to be treated as a .NET for Android
    assembly, fixing the bug.

 3. Assemblies with an assembly reference to `Mono.Android.dll`.

The addition of check (2) allows assemblies with only transitive
(non-) references to `Mono.Android.dll` to be properly considered,
allowing JCWs to be emitted for types within them.

Update the `BuildWithLibraryTests.ProjectDependencies()` unit test to
better check for this scenario.

[0]: https://github.com/xamarin/xamarin-android/wiki/Blueprint#after-build
[1]: https://learn.microsoft.com/en-us/dotnet/android/building-apps/build-targets#signandroidpackage

Changes: https://github.com/xamarin/monodroid/compare/d627218f1e1d0c1e501e2cc36609deb0b09d30aa...21aed734165ab0ea8bcaa1f4151bf13654153327

  * xamarin/monodroid@21aed7341: Bump to xamarin/androidtools/release/8.0.1xx@5b93b9e7 (xamarin/monodroid#1470)
  * xamarin/monodroid@cb085d420: Bump to xamarin-android/release/8.0.2xx@183b7f76 (xamarin/monodroid#1471)
  * xamarin/monodroid@792168d45: Remove "Xamarin" from messages (#1468) (xamarin/monodroid#1469)

Context: dotnet/maui#18757
Context: dotnet/maui#22007
Context: https://github.com/dotnet/maui/blob/440fa7f6ff5602e9cbe23249df5d13c45fb261e1/src/Controls/src/Core/Compatibility/Handlers/ListView/Android/ListViewRenderer.cs#L484-L491
Context: xamarin/monodroid@f4ffb99
Context: 5777337

[`android.view.View.post(Runnable)`][0] adds a `Runnable` callback
to the message queue, to be later run on the UI thread.

Commit xamarin/monodroid@f4ffb99f, imported in 5777337, added a
`View.Post(Action)` overload for this method to make it easier to use.

There is also a [`View.removeCallbacks(Runnable)`][1] method
which allows removing the specified callback from the message queue.
A `View.RemoveCallbacks(Action)` method was also added, permitting:

	Action a = () => …;
	View   v = new View(context);
	v.Post(a);
	v.RemoveCallbacks(a);

To make this work, we needed a way look up the `java.lang.Runnable`
that corresponds to a given `Action`.

Enter `RunnableImplementor` and `RunnableImplementor.instances`:

	namespace Java.Lang;
	partial class Thread {
	    internal partial class RunnableImplementor : Java.Lang.Object, IRunnable {
		public RunnableImplementor (Action handler, bool removable = false);

		public void Run();

		static Dictionary<Action, RunnableImplementor> instances;
		public static RunnableImplementor Remove(Action handler);
	    }
	}

which can be used in the `View` overloads (simplified for exposition):

	namespace Android.Views;
	partial class View {
	    public bool Post(Action action) =>
	        Post(new RunnableImplementor(action, removable: true));
	    public bool RemoveCallbacks(Action action) =>
	    	RemoveCallbacks(RunnableImplementor.Remove(action));
	}

This works, but there's a problem [^0]: when `removable:true` is used,
then `handler` is added to `instances`, and `handler` is only removed
when:

 1. `RunnableImplementor.Run()` is invoked, or
 2. `RunnableImplementor.Remove(Action)` is invoked.

`RunnableImplementor.Remove(Action)` is only invoked if
`View.RemoveAction()` is invoked.

Thus, the question: is there a way to use `View.Post()` and *not*
invoke `RunnableImplementor.Run()`?

Turns Out™, ***Yes***:

	var v = new View(context);
	v.Post(() => …);

then…do nothing with `v`.

While the `View.post(Runnable)` docs state:

> Causes the Runnable to be added to the message queue.
> The runnable will be run on the user interface thread.

that's not *quite* true.

More specifically, the `Runnable`s added to the `View` via
`View.post(Runnable)` are only *actually* added to the message queue
*if and when* the `View` is added to a `Window` [^1].  If the `View`
is never added to a `Window`, then
*all the `Runnable`s are never invoked*.

Which brings us to the C# leak: if we call `View.Post(Action)` and
never add the `View` to a `Window`, then `RunnableImplementor.Run()`
is never executed.  If `RunnableImplementor.Run()` isn't executed,
then the `RunnableImplementor` instance will never be removed from
`RunnableImplementor.instances`, and as `instances` is a "GC root" it
will keep *all of* the `RunnableImplementor` instance, the Java-side
`RunnableImplementor` peer instance (via GREF), and the `Action` alive,
forever.

I could observe this behavior in a MAUI unit test that:

 1. Creates a `ListView`
 2. Creates the platform view that implements `ListView`
 3. Never adds any of these objects to the `Window`
 4. Makes sure none of the things leak -- *this fails*

Fix this by changing `RunnableImplementor.instances` to be a
`ConditionalWeakTable<Action, RunnableImplementor>`.  This *prevents*
`RunnableImplementor.instances` from acting as a GC root, allowing
both the `Action` keys and `RunnableImplementor` values to be
collected.

dotnet/maui#18757 is more or less the same scenario, with one added
Reproduction step that should be called out:

>  * Calling `View.Post(Action)` repeatedly (e.g. in a loop, on a
>    timer etc) will eventually cause the application to crash with
>    the message global reference table overflow

*This particular part is not solvable*.  Android has a GREF limit of
~52000 entries.  If you try to create ~52000 GREFs in a way that
doesn't allow the GC to collect things, then the app will crash, and
there is nothing we can do about it:

	var v = new View(context);
	for (int i = 0; i < 53000; ++i) {
	    int x = i;
	    v.Post(() => Console.WriteLine(x));
	}
	// Boom; attempting to add 53k Actions to a View will require
	// creating 53k `RunnableImplementor` instances, which will
	// create 53k GREFs, which will cause a Very Bad Time™.

TODO: Address [^0] and dispose of the `RunnableImplementor` instance
when `View.Post()` returns `false`.

[0]: https://developer.android.com/reference/android/view/View#post(java.lang.Runnable)
[1]: https://developer.android.com/reference/android/view/View#removeCallbacks(java.lang.Runnable)
[2]: https://cs.android.com/android/platform/superproject/+/main:frameworks/base/core/java/android/view/View.java;l=19618
[3]: https://cs.android.com/android/platform/superproject/+/main:frameworks/base/core/java/android/view/View.java;l=21363


[^0]: There's at least two problems; another problem is that we leak
      if `View.post(Runnable)` returns *false*.
      This will be addressed later.

[^1]: If you never add the `View` to a `Window`, then the `Runnables`
      just hang around until the GC decides to collect them:

       1. When a `View` is *not* attached to a `Window`, then
          `View.mAttachInfo` is null, [so we call `getRunQueue()`][2]:
      
              public boolean post(Runnable action) {
                  …
                  getRunQueue().post(action);
                  return true;
              }
      
       2. `View.getRunQueue()` creates a `HandlerActionQueue`, sets
          `View.mRunQueue`.
      
       3. The only place `View.mRunQueue` is "meaningfully used" is within
          [`View.dispatchAttachedToWindow()`][3], which "transfers" the
          `Runnables` within the `HandlerActionQueue` to the UI handler.

       4. `View.dispatchAttachedToWindow()` is only executed when the
          `View` is attacked to a `Window`.

On 2024-May-01, xamarin/monodroid-samples was updated so that the
`main` branch no longer contained samples for Classic Xamarin.Android.
This in turn meant the removal of the ActionBarSherlock sample.

This change in turn broke xamarin-android unit tests, which attempt
to download this URL, which no longer exists:

  * <https://github.com/xamarin/monodroid-samples/blob/main/ActionBarSherlock/ActionBarSherlock/Jars/ActionBarSherlock-4.3.1.zip?raw=true>

Oops.

As part of the removal of Classic Xamarin.Android samples, a new
`monodroid-samples/archived-xamarin` branch was created, which is
the state of the `main` branch before all old samples were removed.

Update the `BindingBuildTest.RemoveEventHandlerResolution()`
integration test to use the correct URL for ActionBarSherlock.

Context: https://download.mono-project.com/mono-sdks/

`xamjenkinsartifact.blob.core.windows.net` has been decomissioned.

Context: https://github.com/xamarin/xamarin-android-binutils/releases/tag/L_17.0.6-7.1.1
Context: https://github.com/xamarin/xamarin-android-binutils/releases/tag/L_17.0.6-7.1.2
Context: https://github.com/xamarin/xamarin-android-binutils/releases/tag/L_17.0.6-7.2.1
Context: https://github.com/xamarin/xamarin-android-binutils/releases/tag/L_17.0.6-7.2.2
Changes: dotnet/android-native-tools@L_17.0.6-7.1.0...L_17.0.6-7.1.1
Changes: dotnet/android-native-tools@L_17.0.6-7.1.1...L_17.0.6-7.1.2
Changes: dotnet/android-native-tools@L_17.0.6-7.1.2...L_17.0.6-7.2.0
Changes: dotnet/android-native-tools@L_17.0.6-7.2.0...L_17.0.6-7.2.1
Changes: dotnet/android-native-tools@L_17.0.6-7.2.1...L_17.0.6-7.2.2

This release makes changes to how we build and run the `as.exe` wrapper, so that it can be verified by API Scan without any issues.  Otherwise it is identical to the previous release, using the same version of LLVM.

* [ci] Build and sign in a DevDiv pipeline by @pjcollins in dotnet/android-native-tools#7
* [ci] Migrate to the 1ES template by @pjcollins in dotnet/android-native-tools#8
* [ci] Improve binskim scan performance by @pjcollins in dotnet/android-native-tools#11
* [ci] Improve triggers and support test signing by @pjcollins in dotnet/android-native-tools#12
* [ci] Fix unsigned artifact uploading by @pjcollins in dotnet/android-native-tools#13
* [ci] Disable automatic GitHub action trigger by @pjcollins in dotnet/android-native-tools#16
* [ci] Build on performance build pools by @pjcollins in dotnet/android-native-tools#15
* Build `as.exe` on windows by @grendello in dotnet/android-native-tools#10
* [ci] Add API Scan job by @pjcollins in dotnet/android-native-tools#9
*  Fix `as.exe` crash on Windows by @grendello in dotnet/android-native-tools#20
* [ci] Use managed identity for API Scan by @pjcollins in dotnet/android-native-tools#21
* Back to wide strings on Windows + magic encantations by @grendello in dotnet/android-native-tools#22

Context: #8687

In #7963, we added an automatic retry mechanism to the APK test suites.  However this mechanism does not give us a chance to run any tasks between the retry.  

This means that when the tests are run a second time the output directories have not been cleaned and thus we are running incremental builds instead of full builds.  We could unknowingly have tests that always fail on a clean build and succeed on an incremental build.

Thus we are going to remove the automatic retries.  The good news is these test suites seem to be much more stable now than when we implemented the retries, so hopefully this will not result in too many flaky CI builds.

…API levels (#8777)

Fixes: #8331
Context: #8569
Context: dotnet/sdk@25b360d

Building for `net9.0-android33` would give a poor error message:

    error NETSDK1181: Error getting pack version: Pack 'Microsoft.Android.Ref.33' was not present in workload manifests.
    C:\Program Files\dotnet\sdk\8.0.100-preview.7.23376.3\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets

To solve this, you would either change 33 to 34, or just remove the number to rely on the default value.

To make this easier:

* Automatically switch to 34 if the user specifies 33 or less.

* Opt into `%(DefineConstantsOnly)=true` for API levels 21-33 (and not
  the latest), which allows the .NET SDK to emit the *better* .NET SDK
  error message instead.

So now users will get:

    (_CheckForInvalidTargetPlatformVersion target) ->
    dotnet/sdk/9.0.100-alpha.1.23628.5/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.TargetFrameworkInference.targets(243,5):
    error NETSDK1140: 33.0 is not a valid TargetPlatformVersion for Android.
    Valid versions include: 34.0

I added a test for this scenario.

Fixes: #8708

Add README links to Android SDK 13.2.2 packages. (The most recent available.)

Also, remove mention of OSS packages, as the pipeline has not run in 2 years.