Need to support per-ABI mscorlib.dll files

[jonpryor]

As part of the .NET 5 effort, the dotnet/runtime-based mono runtime will support (require?) per-ABI mscorlib.dll files: different files will be used between 32-bit and 64-bit environments and between ARM vs. x86.

Supporting this will require changing at least four separate areas:

1. Installation: we can no longer have just xbuild-frameworks/MonoAndroid/v1.0/mscorlib.dll, but will presumably have xbuild/Xamarin/Android/lib/x86/bcl/mscorlib.dll/etc., one per ABI.

2. Build: Which mscorlib.dll is used for build purposes? Presumably we'd have to preserve xbuild-frameworks/MonoAndroid/v1.0/mscorlib.dll and have it either be a copy of some ABI or be a "reference assembly"?

3. Packaging: The .apk/.aab file will need to add these per-ABI mscorlib.dll files. How do we do that? We currently have a "flat" assemblies/ directory within the .apk to store all assemblies, but that won't work as-is anymore.

4. Runtime: How do we specify which mscorlib.dll gets loaded? Is this something libmonodroid.so needs to explicitly control, or will libmonosgen-2.0.so control it, or...?

Lots of unknowns.

[grendello]

4. libmonodroid.so should do it (pass the path to Mono, most probably, or a pointer)

[jonpryor]

Proposal: the .apk contains an assemblies/[ABI] folder, where [ABI] comes from BasicAndroidSystem::android_abi_names: https://github.com/xamarin/xamarin-android/blob/master/src/monodroid/jni/basic-android-system.hh#L21-L25

Then when looking for an assembly, we for assemblies/[ABI]/ASSEMBLY.dll first before falling back to assemblies/ASSEMBLY.dll.

[grendello]

Do we expect to have more assemblies like mscorlib.dll? If not, then we should just special-case it and save time on the runtime

[akoeplinger]

(2) isn't your concern anymore with .NET 5. There's a reference assembly that will be used to compile the app/library code against.

[marek-safar]

I think (1) installation is something what XA won't control at all

[pjcollins]

The entire BCL will need to be treated in this way by my understanding, not just mscorlib.

Both 1 and 2 should be handled by the .NET Core installation / build system. At build time, our project will compile against the "reference assembly" version of these assemblies which will be resolved through the TargetingPack portion of the Microsoft.NETCore.App FrameworkReference.

This FrameworkReference maps the non-RID specific reference assemblies from the TargetingPack to the corresponding RuntimePack assets based on the RID(s) specified by the project. There is an msbuild task we could potentially lean on at package time (3) to make sure we scoop up the correct runtime files on disk and put them in the correct place in the .apk

I like the proposal of introducing a assemblies/[ABI] folder, but perhaps instead of [ABI] we want to use the architecture portion of our soon to be created Android RIDs? For example,

• x86, x64, arm, or arm64.

instead of

• x86, x86_64, armeabi-v7a, or arm64-v8a.

I'm not sure if that is any worse or better than the ABI proposal, either way I think we'll need to map $(AndroidSupportedAbis) to $(RuntimeIdentifiers) in various places in our build system.

[akoeplinger]

The entire BCL will need to be treated in this way by my understanding, not just mscorlib.

No, System.Private.CoreLib.dll is the only managed assembly with this architecture-specific build right now.

[grendello]

@pjcollins if we're to treat the entire BCL like this then we'll be in trouble wrt apk size for multi-arch apps. Well, I guess we're going to have a size increase problem anyway...

[grendello]

@akoeplinger I guess we shouldn't assume this is going to remain unchanged... We need to come up with a mechanism that deals with it now, trying to pay as small price as possible both regarding the apk size and the runtime performance. Is there any way to tell an arch-specific assembly from a "pure" managed one?

[marek-safar]

@grendello why does it matter? isn't the app bundle size not relevant?

[grendello]

@marek-safar if we ship AAB then it (mostly) doesn't matter as long as Google Play Store can determine how to split it up - in this case we most probably need to put the arch-specific assemblies in the lib/[ARCH] dir. In the case of a regular .apk, we'll be shipping everything to everybody as I don't think regular .apks are split up on upload to Play Store (but maybe I'm wrong?)

[marek-safar]

Is this actual problem if AAB does know how to handle it correctly?

[grendello]

@marek-safar until AAB is the only way to distribute Android apps, it is a problem, yes.

[marek-safar]

Why? Devs have 2 options when they target a single target and 1 option if they target more than 1 target so we have solution nonetheless

[grendello]

@marek-safar Devs have 3 options:

1. single apk with all the arch-specific bits for all the supported architectures
2. single apk per architecture
3. single aab

[ghost]

We suspect this issue is stale and no longer relevant. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

[ghost]

This issue will now be closed since it had been marked possibly-stale but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.