Rethink .NET Workload Pack Structure

[jonpryor]

Android application type

Android for .NET (net6.0-android, etc.)

Affected platform version

.NET 6.0.400 / 32.0.440

Description

Context? 0ab3db0

Today, when we build a .NET 6 app, we build the app against the latest runtime pack, no matter what $(TargetFramework) was specified. If $(TargetFramework)=net6.0-android (API-31), then the app assembly is built against the API-31 reference pack, but the App is packaged using the API-33 assemblies.

The result is that in some circumstances, API-33 members may be used by Java Callable Wrappers, even if API-33 isn't installed; even if API-33 android.jar is installed, it won't be used by JCW compilation.

---

The original reason for using the latest runtime pack during app build (TODO: commit?) is because libmonodroid.so (via libmono-android.debug.so, libmono-android.release.so, and libxamarin-debug-app-helper.so) is "tied at the hip" to Xamarin.Android.Build.Tasks.dll (XABT), as XABT emits LLVM-IR/assembly/etc. which depends upon internals of libmonodroid.so. As the runtime pack contains the libmonodroid.so files, it thus felt appropriate to always use the latest runtime pack, as that was the version that would match the SDK pack (which contains XABT).

We are now hitting an unexpected corner case of this arrangement.

What we should instead do is place related components into the same pack. As libmonodroid.so & XABT are tied to each other, libmonodroid.so should instead be distributed in the SDK packs, not the runtime packs.

Steps to Reproduce

Create a new Android app:

dotnet new android -n implicit_api33

Edit MainActivity.cs to add:

sealed class MyThread : global::Java.Lang.Thread
{
}

Build the app.

Expected results: it builds! (It does build with .NET 6.0.300…)

Actual results (with .NET 6.0.400): it doesn't build; Java Callable Wrapper compilation fails:

JAVAC0000 error: no suitable constructor found for Thread(ThreadGroup,Runnable,String,long.boolean)

Did you find any workaround?

Build the app against API-33, by setting $(TargetFramework)=net6.0-android33.0.

Relevant log output

No response

[jonpryor]

Via:

• https://discord.com/channels/732297728826277939/732297837953679412/999317617301004419
• https://discord.com/channels/732297728826277939/732297837953679412/999320933057708162
• https://discord.com/channels/732297728826277939/732297837953679412/999337106541379675
• https://discord.com/channels/732297728826277939/732297837953679412/999342033888096297

[jonpryor]

Context: #7183
Context: https://bugzilla.xamarin.com/11/1114/bug.html
Context: https://bugzilla.xamarin.com/23/2367/bug.html
Context: https://github.com/xamarin/monodroid/commit/8c03aba6aabeec7fbd5a7425aeff9d73a4a19952
Context: https://github.com/xamarin/monodroid/commit/78ab9b5539d031ff3c334430295b6e2fcb346498
Context: https://github.com/xamarin/monodroid/commit/6679dfc62eae462b5acc9deb095d0fa41786f80b

Background: Java Callable Wrapper (JCW) constructors! Consider the
following C# class:

public class MyThread1 : Java.Lang.Thread {
}

This type has one constructor: the implicit default constructor.

How many constructors does the JCW contain?

At least 8:

// Java
public /* partial */ class MyThread1 extends java.lang.Thread /* … */ {
    public MyThread1();
    public MyThread1(Rnnable target);
    public MyThread1(ThreadGroup group, Runnable target);
    public MyThread1(String name);
    public MyThread1(ThreadGroup group, String name);
    public MyThread1(Runnable target, String name);
    public MyThread1(ThreadGroup group, Runnable target, String name);
    public MyThread1(ThreadGroup group, Runnable target, String name, long stackSize);
}

Wait, what? Why? Constructor generation is unexpectedly hard.

Aside: consider the binding for the Thread(String) constructor:

/* partial */ class Thread : Object, IRunnable {
    [Register (".ctor", "(Ljava/lang/String;)V", "")]
    public unsafe Thread (string name) : base (IntPtr.Zero, JniHandleOwnership.DoNotTransfer)
    {
        const string __id = "(Ljava/lang/String;)V";

        if (((global::Java.Lang.Object) this).Handle != IntPtr.Zero)
            return;

        IntPtr native_name = JNIEnv.NewString ((string?)name);
        try {
            JniArgumentValue* __args = stackalloc JniArgumentValue [1];
            __args [0] = new JniArgumentValue (native_name);
            var __r = _members.InstanceMethods.StartCreateInstance (__id, ((object) this).GetType (), __args);
            SetHandle (__r.Handle, JniHandleOwnership.TransferLocalRef);
            _members.InstanceMethods.FinishCreateInstance (__id, this, __args);
        } finally {
            JNIEnv.DeleteLocalRef (native_name);
        }
    }
}

The key part are the calls to
[JniPeerMembers.JniInstanceMethods.StartCreateInstance()][0] and
[JniPeerMembers.JniInstanceMethods.FinishCreateInstance()][1], which:

1. Gets the JCW corresponding to the runtime type this.GetType(),
   i.e. MyThread1

2. Looks up the Java-side constructor on the JCW from (1) which has
   the JNI signature in __id.

For MyThread1, this will lookup the MyThread1() default
constructor in the JCW.

Now consider MyThread2:

// C#
public class MyThread2 : Thread {
    public MyThread2()
        : base ("name)
    {
    }
}

Here, the MyThread2() default constructor invokes the
Java.Lang.Thread(string) constructor, which will attempt to find
the Java Callable Wrapper constructor MyThread2(String)! This in
turn requires that the MyThread2(String) constructor exist.

We cannot have a "direct" relationship between the managed type and
the Java Callable Wrapper. At minimum, there needs to be a
MyThread2(String) constructor, even though MyThread2 doesn't have
such a constructor.

The only way to know which constructors need to be generated is by
disassembling the IL to see which constructor is invoked, which was
more work than we wanted to do.

So what we instead do is emit all possible constructor overloads.
This ensures that the MyThread2(String) JCW constructor will exist
when needed, at the cost of extra unusable constructors also existing.

So far so good; things have worked this way for over 10 years.