[Xamarin.Android.Build.Tasks] MAM Member Remapping?

[jonpryor]

[Mono.Android] Type & Member Remapping Support

Context: dotnet/java-interop#936
Context: #6142 (comment)

Fixes: dotnet/java-interop#867

~~ The Scenarios ~~

Our Java binding infrastructure involves looking up types and methods
via JNI, and assumes that types and methods won't "move" in an
unexpected manner. Methods which move from a subclass to a
superclass works transparently. Methods which are moved to an
entirely different class causes us problems.

Case in point: desugaring, which can move Java types to places
that our bindings don't expect. For example, Arrays.stream(T[])
may be moved into a DesugarArrays class, or a default interface
method Example.m() may be moved into an Example$-CC type.
Java.Interop has not supported such changes, resulting in throwing a
Java.Lang.NoSuchMethodError on Android versions where methods are
not where we expect.

Additionally, the InTune Mobile Application Management team
needs a expanded type and member lookup mechanism in order to
simplify how they maintain their product. Currently they make things
work by rewriting IL, which can be brittle.

~~ The Pieces ~~

To improve support for this, dotnet/java-interop#936 introduces
new virtual methods into Java.Interop.JniRuntime.JniTypeManager
which are called as part of type and member lookup, allowing
AndroidTypeManager to participate in the type and member resolution
process.

AndroidTypeManager in turn needs to know what types and members can
be remapped, and what they should be remapped to. Some of these can
be algorithmic, such as pre-pending Desugar or appending $-CC for
the Desugar case.

The InTune use case involves a table, contained within the
Microsoft.Intune.MAM.Remapper.Tasks NuGet package.

Update src/Xamarin.Android.Build.Tasks to add a new
@(_AndroidMamMappingFile) Build action. Files with this build
action are expected to be JSON documents which follow the current
conventions of remapping-config.json, within the
Microsoft.Intune.MAM.Remapper.Tasks NuGet package. This build
action is not externally supported; this is currently for testing
purposes. @(_AndroidMamMappingFile) files are processed into an
XML intermediary as part of the App build, and bundled into the app
as an @(AndroidAsset) named xa-internal/xa-mam-mapping.xml:

<replacements>
  <replace-type
      from="android/app/Activity"
      to="com/microsoft/intune/mam/client/app/MAMActivity" />
  <replace-method
      source-type="com/microsoft/intune/mam/client/app/MAMActivity"
      source-method-name="onCreate" source-method-signature="(Landroid/os/Bundle;)"
      target-type="com/microsoft/intune/mam/client/app/MAMActivity"
      target-method-name="onMAMCreate" target-method-instance-to-static="false" />
</replacements>

//replacements/replace-method is structured with each attribute
corresponding to a member on the JniRuntime.ReplacementMethodInfo
struct, in dotnet/java-interop#936.

• //replace-method/@source-type is
  JniRuntime.ReplacementMethodInfo.SourceJniType
• //replace-method/@source-method-name is
  JniRuntime.ReplacementMethodInfo.SourceJniMethodName
• //replace-method/@source-method-signature is
  JniRuntime.ReplacementMethodInfo.SourceJniMethodSignature
• //replace-method/@target-type is
  JniRuntime.ReplacementMethodInfo.TargetJniType
• //replace-method/@target-method-name is
  JniRuntime.ReplacementMethodInfo.TargetJniMethodName
• //replace-method/@target-method-signature is
  JniRuntime.ReplacementMethodInfo.SourceJniMethodSignature
• //replace-method/@target-method-instance-to-static is
  JniRuntime.ReplacementMethodInfo.TargetJniMethodIsStatic

During app startup on the Android device, the
xa-internal/xa-mam-mapping.xml asset is opened and provided to
JNIEnv.Initialize() as part of native app startup.

~~ Putting it all together ~~

This will only work on .NET 7+.

App project has a @(_AndroidMamMappingFile) file. This item is
processed during App build, stored into the .apk, and read during
app startup on an Android device.

Given a Java binding such as:

public partial class Activity {
    static readonly JniPeerMembers _members = new XAPeerMembers ("android/app/Activity", typeof (Activity));
}

when the JniPeerMembers constructor runs, it will call
JniEnvironment.Runtime.TypeManager.GetReplacementType("android/app/Activity").
If @(_AndroidMamMappingFile) uses the InTune remapping-config.json
file, then com/microsoft/intune/mam/client/app/MAMActivity will
be resolved via JNIEnv::FindClass(), not android/app/Activity.

If MAMActivity can't be found, e.g. you're testing this all out,
the app will ~immediately crash, as MAMActivity doesn't exist. 😅

If MAMActivity can be found, eventually Activity.OnCreate() will
need to be invoked:

partial class Activity {
    protected virtual unsafe void OnCreate (Android.OS.Bundle? savedInstanceState)
    {
        const string __id = "onCreate.(Landroid/os/Bundle;)V";
        try {
            JniArgumentValue* __args = stackalloc JniArgumentValue [1];
            __args [0] = new JniArgumentValue ((savedInstanceState == null) ? IntPtr.Zero : ((global::Java.Lang.Object) savedInstanceState).Handle);
            _members.InstanceMethods.InvokeVirtualVoidMethod (__id, this, __args);
        } finally {
            global::System.GC.KeepAlive (savedInstanceState);
        }
    }
}

_members.InstanceMethods.InvokeVirtualVoidMethod() will internally
make a call similar to:

var r = JniEnvironment.Runtime.TypeManager.GetReplacementMethodInfo (
    "android/app/Activity",
    "onCreate",
    "(Landroid/os/Bundle;)V"
);

The data returned will be equivalent to:

var r = new JniRuntime.ReplacementMethodInfo {
    SourceJniType                   = "android/app/Activity",                               // from input parameter
    SourceJniMethodName             = "onCreate",                                           // from input parameter
    SourceJniMethodSignature        = "(Landroid/os/Bundle;)V",                             // from input parameter

    TargetJniType                   = "com/microsoft/intune/mam/client/app/MAMActivity",    // from //replace-method/@target-type
    TargetJniMethodName             = "onMAMCreate",                                        // from //replace-method/@target-method-name
    SourceJniMethodSignature        = "(Landroid/os/Bundle;)V",                             // from input parameter, as signature didn't change
    TargetJniMethodParameterCount   = 1,                                                    // computed based on signature
    TargetJniMethodIsStatic         = false,                                                // from //replace-method/@target-method-instance-to-static
}

This will allow _members.InstanceMethods.InvokeVirtualVoidMethod()
to instead resolve and invoke MAMActivity.onMAMCreate().

[jonathanpeppers]

Should we really put this in the Hello World project? Should it maybe be an MSBuild test in Xamarin.Android.Build.Tests?

[jonpryor]

No. This should be removed before merging. It's mostly for the InTune team to see the item group to use and the filename currently supported.

I don't think we can put it into a test project either, because it doesn't work right now: the HelloWorld.DotNet.csproj approach causes the app to cash at startup because MAMActivity can't be found, which is fair because it doesn't exist in the app.

If we extract classes.jar from Microsoft.Intune.MAM.Xamarin.Android, a'la dotnet/java-interop#936 (comment), it still crashes at startup, because:

JNI DETECTED ERROR IN APPLICATION: can't call void com.microsoft.intune.mam.client.app.MAMActivity.onMAMCreate(android.os.Bundle) on instance of example.MainActivity

which is likewise "fair", because the example.MainActivity Java bytecode wasn't updated by the InTune tooling, because the tooling didn't run.

If we try to do this "more correctly":

    <PackageReference
        Include="Microsoft.Intune.MAM.Xamarin.Android"
        Version="3.0.4635.1"
    />

it doesn't build, because .NET 7 doesn't have Microsoft.Build.Utilities.v4.0.dll:

$HOME/.nuget/packages/xamarin.android.support.annotations/28.0.0.1/build/monoandroid90/Xamarin.Android.Support.Annotations.targets(17,3): error MSB4062: The "Xamarin.Android.Support.BuildTasks.VerifyVersionsTask" task could not be loaded from the assembly $HOME/.nuget/packages/xamarin.android.support.annotations/28.0.0.1/build/monoandroid90/Xamarin.Android.Support.BuildTasks.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

Right now, I don't think we can have an "end-to-end using InTune" test.

We could -- should? -- have a "lesser" test, which uses the remap-mam-json-to-xml output format directly along with a small set of Java files, and this would be useful to test things, but it wouldn't include InTune.

[jonpryor]

Beginnings of a "lesser" test just pushed, via introduction of a new @(_AndroidRemapMembers) build action. This uses the same XML format that the InTune JSON is converted to, so we can test things by writing our XML format directly, instead of going through a JSON intermediary.

TODO: add an actual on-device unit test which does this.

[jonathanpeppers]

Probably still a lot of jonp print statements throughout.

[jonpryor]

Once the basics are settled, I'll remove them. :-)

[jonathanpeppers]

Instead of using XML here at all, could we generate a type in the main assembly that has this data? So you would just use reflection to look for a couple well-known class and field names?

Maybe that is more work than we're willing to do right now.

[jonpryor]

See my other comment, but…. We don't want to "privilege" the "main" assembly ("what's a main assembly?"), because when we have, things break; see e.g. 807e665, wherein an app crashed because the Activity launched wasn't in the "main" assembly.

The "best" fix is to put this data into libxamarin-app.so. I think we can do that by e.g. .NET 7 P7.

[jonathanpeppers]

If we went with the C# code generation idea, maybe this class could write a .cs file instead of XML? We don't have any Roslyn source-generators yet, so that would probably be the simplest route.

[jonpryor]

Yes, but…

The question is where to put this data? A source generator means "put it into the main assembly", and obtaining that data from the main assembly from JNIEnv.Initialize() sounds like A Bad Time™.

Instead, the mid-term solution should be to instead put this data into libxamarin-app.so, as a build-time action.

[jonpryor]

@dellis1972 , @jonathanpeppers : please review this test for sanity. :-)

(I have no idea what I'm doing here. [dog-on-keyboard.gif])

[jonathanpeppers]

The other XASdkTests class has some helper methods:

https://github.com/xamarin/xamarin-android/blob/1efa0cf46c9079fc06669a4434f597faf47504af/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/XASdkTests.cs#L1071-L1094

Should we put these somewhere, so that XASdkDeployTests can use them?

Then you can do:

var builder = CreateDotNetBuilder (proj);
Assert.IsTrue (builder.Build (), $`dotnet build` should succeed");

[dellis1972]

This test looks good. But making use of methods like CreateDotNetBuilder would make it a bit nicer :)

[dellis1972]

I think (and @jonathanpeppers can correct me :) ) we tend to prefer that we explicitly define the dependencies in
src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.BuildOrder.targets for .NET and src/Xamarin.Android.Build.Tasks/Xamarin.Android.Legacy.targets for Legacy. We can do this in addition to DependsOnTargets but it does help when figuring out the build order if we have it in the other files too.

This is for .NET 7+ only right?

[jonpryor]

Correct, this is .NET 7+ only.

[jonpryor]

This test never runs, for reasons I cannot currently explain or fathom. It's in the downloaded MSBuildDeviceIntegration.dll. It's not [Values]; ApplicationRunsWithoutDebugger is run. It's not position in the file (moving it didn't change anything).

Meanwhile, I can run it locally, via the updated docs:

./dotnet-local.sh test bin/TestDebug/MSBuildDeviceIntegration/net6.0/MSBuildDeviceIntegration.dll --filter "Name~TypeAndMemberRemapping"

Fortunately, type and member remapping is also tested as part of Java.Interop-Tests.dll, included in Mono.Android.NET-Tests.apk, so I'm confident it works. It would just be nice if this test also worked. Or at least ran.

[jonathanpeppers]

Wait was this failing on main? I just merged this one and it was completely green: #6986

So is something in this PR causing these to show up in apps now?

[jonpryor]

Yes; probably the new XmlReader use in JNIEnv.Initialize().

Presumably these will "disappear" once we do the "non-prototype" approach of putting al this data into libxamarin-app.so…

[jonathanpeppers]

Using System.Xml bloats app size a lot... So now we are doing it for all apps?

[jonpryor]

This week? Yes.

Once we get all this re-hosted on libxamarin-app.so, no.

[grendello]

Should it point to JI/main?

[jonpryor]

Yes, when dotnet/java-interop#936 is merged, but not until then.

Please review dotnet/java-interop#936 ;-)

[grendello]

It might be faster and more memory conservative to do

var desugarType = slash <= 0
? new StringBuilder ("Desugar").Append (jniSimpleReference).ToString ()
: new StringBuilder (jniSimpleReference.Substring (0, slash+1)).Append ("Desugar").Append(jniSimpleReference.Substring (slash+1)).ToString ();

And potentially use Span<T>.Slice instead of .Substring

[grendello]

Should this go in?

[grendello]

Ditto

[grendello]

Ditto

[grendello]

It might be faster to use out parameters for the dictionaries, to avoid instantiating a tuple

[jonpryor]

will be moot once this is all in libxamarin-app.so. :-)

[grendello]

Ditto wrt tuple

[grendello]

I don't know how important it is, but this form of assignment will silently overwrite the previous value, if any. Perhaps .Add (key, val) would be better?

[jonpryor]

And chance an exception if there are duplicates?

Something to consider in future revisions.

[grendello]

Well, it depends on whether it matters or not. If it's not an error to overwrite an earlier value, then this code's fine :)

[grendello]

I wish we could somehow kill this monster of a method... So many arguments :)

[grendello]

Ditto logging

[jonpryor]

For now, i'll leave this in so that there is some runtime indicator that mapping is being used, but i'll move it into the above if block so it's only printed when used.

[jonpryor]

[Mono.Android] Type & Member Remapping Support

Fixes: https://github.com/xamarin/java.interop/issues/867

Context: https://github.com/xamarin/java.interop/commit/1f27ab552d03aeb74cdc6f8985fcffbfdb9a7ddf
Context: https://github.com/xamarin/xamarin-android/issues/6142#issuecomment-889435599
Context: https://github.com/xamarin/xamarin-android/issues/7020

Changes: https://github.com/xamarin/java.interop/compare/843f3c7817dc4bdae9ce69d04274f29fce574e09...1f27ab552d03aeb74cdc6f8985fcffbfdb9a7ddf

  * xamarin/java.interop@1f27ab55: [Java.Interop] Type & Member Remapping Support (#936)
  * xamarin/java.interop@02aa54e0: [Java.Interop.Tools.JavaCallableWrappers] marshal method decl types (#987)
  * xamarin/java.interop@e7bacc37: [ci] Update azure-pipelines.yaml to Pin .NET 6.0.202 (#986)
  * xamarin/java.interop@fb94d598: [Java.Interop.Tools.JavaCallableWrappers] Collect overriden methods (#985)
  * xamarin/java.interop@3fcce746: [Java.Interop.{Dynamic,Export}] Nullable Reference Type support (#980)

~~ The Scenarios ~~

Our Java binding infrastructure involves looking up types and methods
via [JNI][0], and assumes that types and methods won't "move" in an
unexpected manner.  Methods which move from a subclass to a
superclass works transparently.  Methods which are moved to an
entirely different class causes us problems.

Case in point: [desugaring][0], which can *move* Java types to places
that our bindings don't expect.  For example, [`Arrays.stream(T[])`][1]
may be moved into a `DesugarArrays` class, or a default interface
method `Example.m()` may be moved into an `Example$-CC` type.
Java.Interop has not supported such changes, resulting in throwing a
`Java.Lang.NoSuchMethodError` on Android versions where methods are
not where we expect.

Additionally, the [InTune Mobile Application Management][3] team
needs a expanded type and member lookup mechanism in order to
simplify how they maintain their product.  Currently they make things
work by rewriting IL, which can be brittle.


~~ Build actions ~~

To improve support for this, xamarin/java.interop#936 introduces
new `virtual` methods into `Java.Interop.JniRuntime.JniTypeManager`
which are called as part of type and member lookup, allowing
`AndroidTypeManager` to participate in the type and member resolution
process.

`AndroidTypeManager` in turn needs to know what types and members can
be remapped, and what they should be remapped to.  Some of these can
be algorithmic, such as pre-pending `Desugar` or appending `$-CC` for
the Desugar case.

The InTune use case involves a table, contained within the
[Microsoft.Intune.MAM.Remapper.Tasks NuGet package][4].

Update `src/Xamarin.Android.Build.Tasks` to add a new
`@(_AndroidRemapMembers)` Build action.  This build action is not
externally supported; it's to help test the feature.  Files with this
build action are XML files which control type and member remapping:

	<replacements>
	  <replace-type
	      from="android/app/Activity"
	      to="com/microsoft/intune/mam/client/app/MAMActivity" />
	  <replace-method
	      source-type="com/microsoft/intune/mam/client/app/MAMActivity"
	      source-method-name="onCreate" source-method-signature="(Landroid/os/Bundle;)V"
	      target-type="com/microsoft/intune/mam/client/app/MAMActivity"
	      target-method-name="onMAMCreate" target-method-instance-to-static="false" />
	</replacements>

`//replacements/replace-method` is structured with each attribute
corresponding to a member on the `JniRuntime.ReplacementMethodInfo`
structure, in xamarin/java.interop@1f27ab55.

  * `//replace-method/@source-type` is
    `JniRuntime.ReplacementMethodInfo.SourceJniType`
  * `//replace-method/@source-method-name` is
    `JniRuntime.ReplacementMethodInfo.SourceJniMethodName`
  * `//replace-method/@source-method-signature` is
    `JniRuntime.ReplacementMethodInfo.SourceJniMethodSignature`
  * `//replace-method/@target-type` is
    `JniRuntime.ReplacementMethodInfo.TargetJniType`
  * `//replace-method/@target-method-name` is
    `JniRuntime.ReplacementMethodInfo.TargetJniMethodName`
  * `//replace-method/@target-method-signature` is
    `JniRuntime.ReplacementMethodInfo.TargetJniMethodSignature`
    This attribute is optional.
  * `//replace-method/@target-method-parameter-count` is
    `JniRuntime.ReplacementMethodInfo.TargetJniMethodParameterCount`.
    This attribute is optional.
  * `//replace-method/@target-method-instance-to-static` is
    `JniRuntime.ReplacementMethodInfo.TargetJniMethodIsStatic`

`@source-type`, `@source-method-name`, and `@source-method-signature`
combined serve as a "key" for looking up the associated `@target-*`
information.

Update `src/Xamarin.Android.Build.Tasks` to add a new
`@(_AndroidMamMappingFile)` Build action.  This build action is not
externally supported; it's to help test the feature.  Files with this
build action are expected to be JSON documents which follow the
current conventions of `remapping-config.json`, within the
`Microsoft.Intune.MAM.Remapper.Tasks` NuGet package.  This build
action is not externally supported; this is currently for testing
purposes.  `@(_AndroidMamMappingFile)` files are processed at build
time into `@(_AndroidRemapMembers)` XML files.

During App builds, all `@(_AndroidRemapMembers)` files are merged
into an `@(AndrodAsset)` named `xa-internal/xa-mam-mapping.xml`.
This asset is opened and provided to `JNIEnv.Initialize()` as part of
native app startup.


~~ Putting it all together ~~

This will only work on .NET 7+.

App project has a `@(_AndroidRemapMembers)` file.  This item is
processed during App build, stored into the `.apk`, and read during
app startup on an Android device.

Given a Java binding such as:

	public partial class Activity {
	    static readonly JniPeerMembers _members = new XAPeerMembers ("android/app/Activity", typeof (Activity));
	}

when the `JniPeerMembers` constructor runs, it will call
`JniEnvironment.Runtime.TypeManager.GetReplacementType("android/app/Activity")`.
If `@(_AndroidRemapMembers)` is based on the InTune
`remapping-config.json` file, then `android/app/Activity` is mapped
to `com/microsoft/intune/mam/client/app/MAMActivity`, and
`JNIEnv::FindClass()` will be told to lookup `MAMActivity`, *not*
`Activity`.

*If `MAMActivity` can't be found*, e.g. you're testing this all out,
the app will ~immediately crash, as `MAMActivity` doesn't exist. 😅

If `MAMActivity` can be found, eventually `Activity.OnCreate()` will
need to be invoked:

	partial class Activity {
	    protected virtual unsafe void OnCreate (Android.OS.Bundle? savedInstanceState)
	    {
	        const string __id = "onCreate.(Landroid/os/Bundle;)V";
	        try {
	            JniArgumentValue* __args = stackalloc JniArgumentValue [1];
	            __args [0] = new JniArgumentValue ((savedInstanceState == null) ? IntPtr.Zero : ((global::Java.Lang.Object) savedInstanceState).Handle);
	            _members.InstanceMethods.InvokeVirtualVoidMethod (__id, this, __args);
	        } finally {
	            global::System.GC.KeepAlive (savedInstanceState);
	        }
	    }
	}

`_members.InstanceMethods.InvokeVirtualVoidMethod()` will internally
make a call similar to:

	var r = JniEnvironment.Runtime.TypeManager.GetReplacementMethodInfo (
	    "com/microsoft/intune/mam/client/app/MAMActivity",
	    "onCreate",
	    "(Landroid/os/Bundle;)V"
	);

The data returned will be equivalent to:

	var r = new JniRuntime.ReplacementMethodInfo {
	    SourceJniType                   = "com/microsoft/intune/mam/client/app/MAMActivity",    // from input parameter
	    SourceJniMethodName             = "onCreate",                                           // from input parameter
	    SourceJniMethodSignature        = "(Landroid/os/Bundle;)V",                             // from input parameter

	    TargetJniType                   = "com/microsoft/intune/mam/client/app/MAMActivity",    // from //replace-method/@target-type
	    TargetJniMethodName             = "onMAMCreate",                                        // from //replace-method/@target-method-name
	    TargetJniMethodSignature        = "(Landroid/os/Bundle;)V",                             // from input parameter, as signature didn't change
	    TargetJniMethodParameterCount   = 1,                                                    // computed based on signature
	    TargetJniMethodIsStatic         = false,                                                // from //replace-method/@target-method-instance-to-static
	}

This will allow `_members.InstanceMethods.InvokeVirtualVoidMethod()`
to instead resolve and invoke `MAMActivity.onMAMCreate()`.


~~ Tools ~~

`tools/remap-mam-json-to-xml` is added, and will process the InTune
JSON file into `@(_AndroidRemapMembers)` XML:

	$ dotnet run --project tools/remap-mam-json-to-xml  -- \
	  $HOME/.nuget/packages/microsoft.intune.mam.remapper.tasks/0.1.4635.1/content/MonoAndroid10/remapping-config.json
	<replacements>…


~~ Unit Tests ~~

`@(_AndroidRemapMembers)` usage is required by
`Mono.Android.NET-Tests.apk`, as `Java.Interop-Tests.dll` exercises
the type and member remapping logic.


~~ Unrelated `gref+` logging fixes ~~

When `debug.mono.log` = `gref+`, the app could crash:

	signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x79c045dead

This was likely because a constant string was provided to
`OSBridge::_write_stack_trace()`, which tried to write into the
constant string, promptly blowing things up.

Workaround: don't use `gref+` logging when a GC occurs?
(Fortunately, `gref+` logging isn't the default.)

Better workaround: Don't Do That™. Don't write to const strings.


~~ About `@(_AndroidRemapMembers)` Semantics… ~~

 1. Changing the Java hierarchy "requires" changing the managed
    hierarchy to mirror it.

    If we rename `Activity` to `RemapActivity` but *don't* change
    `MainActivity` to inherit the (bound!) `Example.RemapActivity`,
    the app *crashes*:

        JNI DETECTED ERROR IN APPLICATION: can't call void example.RemapActivity.onMyCreate(android.os.Bundle) on instance of example.MainActivity

    This can be "fixed" *without* changing the base class
    of `MainActivity` by instead changing the base class of the
    Java Callable Wrapper for `MainActivity` to `example.RemapActivity`.
    This can be done manually (just edit the files in `obj/…`!), but
    isn't really supported in "normal" xamarin-android usage
    (the next Clean will wipe your changes).

    Presumably InTune would make this Just Work by e.g. patching the
    `MainActivity.class` file.

 2. `/replacements/replace-type` interacts with
    `/replacements/replace-method`: at runtime, `//replace-type@from`
    *no longer exists*, meaning you ***cannot*** use that name
    in `//replace-method/@source-type` either!

    If `Activity` is remapped to `RemapActivity`, then *there is no*
    `Activity.onCreate()` method to similarly remap.  Instead, you
    need to specify `RemapActivity.onCreate()`.

    This warps the brain a bit.

    This:

        <replace-method
            source-type="example/RemapActivity"
            source-method-name="onCreate"
            target-type="example/RemapActivity"
            target-method-name="onMyCreate" target-method-instance-to-static="false" />

    not this:

        <replace-method
            source-type="android/app/Activity"
            source-method-name="onCreate"
            target-type="example/RemapActivity"
            target-method-name="onMyCreate" target-method-instance-to-static="false" />

 3. Don't intermix type renames with
    `/replace-method/@target-method-instance-to-static='true']`.
    It *can* be done, but also warps the brain.

    The deal with `@target-method-instance-to-static` is that it
    it changes the target method signature -- unless explicitly
    provided in `/replace-method/@target-method-signature` --
    so that the "source declaring type" is a prefix.

    Thus given

        <replace-method
            source-type="android/view/View"
            source-method-name="setOnClickListener"
            target-type="example/ViewHelper"
            target-method-name="mySetOnClickListener" target-method-instance-to-static="true" />

    we'll look for `ViewHelper.mySetOnClickListener(View, View.OnClickListener)`.

    If we renamed `View` to `MyView`, we would instead look for
    `ViewHelper.mySetOnClickListener(MyView, View.OnClickListener)`
    (note changed parameter type).

    This almost certainly *won't* work.


~~ InTune Integration Testing? ~~

For "more complete" InTune integration testing, one will want the
path to `remapping-config.json`, without hardcoding things.
This can be done with `%(PackageReference.GeneratePathProperty)`=True
and using `$(PkgMicrosoft_Intune_MAM_Remapper_Tasks)`:

	<ItemGroup>
	  <PackageReference
	      Include="Microsoft.Intune.MAM.Remapper.Tasks"
	      Version="0.1.4635.1"
	      IncludeAssets="none"
	      GeneratePathProperty="True"
	      ReferenceOutputAssembly="False"
	  />
	</ItemGroup>
	<Target Name="_AddMamFiles"
	    BeforeTargets="_AddAndroidCustomMetaData">
	  <ItemGroup>
	    <_AndroidMamMappingFile Include="$(PkgMicrosoft_Intune_MAM_Remapper_Tasks)/content/MonoAndroid10/remapping-config.json" />
	  </ItemGroup>
	</Target>

This is still fraught with some peril, as it likely also depends on
getting the right "inner" build, which may require using the plural
`$(TargetFrameworks)` property, not the singular `$(TargetFramework)`.
This might still be a useful start.


~~ TODO ~~

Optimize this mess:
https://github.com/xamarin/xamarin-android/issues/7020

[0]: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html
[1]: https://developer.android.com/studio/write/java8-support#library-desugaring
[2]: https://developer.android.com/reference/java/util/Arrays#stream(T[])
[3]: https://docs.microsoft.com/en-us/mem/intune/fundamentals/what-is-intune
[4]: https://www.nuget.org/packages/Microsoft.Intune.MAM.Remapper.Tasks/