[.NET 10] investigate how to ship fewer copies of Mono.Android.dll

[jonathanpeppers]

Android framework version

Other

Affected platform version

.NET 10

Description

Right now we have this many Mono.Android.dll

• ref pack, reference assembly for Mono.Android.dll
• android-arm Mono.Android.dll
• android-arm64 Mono.Android.dll
• android-x86 Mono.Android.dll
• android-x64 Mono.Android.dll

Where the last four are identical, because it's managed code and not tied to a RID at all. Ideally, we could reduce this to 1 ref assembly and 1 runtime assembly.

This is going to get even worse if we support multiple runtimes in the future: NativeAOT, etc.

Steps to Reproduce

1. dotnet workload install android
2. Look at the Mono.Android.dll files on disk.

Did you find any workaround?

n/a

Relevant log output

[jpobst]

This is going to get even worse if we support multiple runtimes in the future: NativeAOT, etc.

Also with Google now releasing APIs twice a year, it's going to get worse due to supporting multiple API Levels per .NET version.

[jonpryor]

I thought I had asked/commented somewhere, "Is there a reason for us to have per-RID binaries?" Alas, I can't find me actually asking that, but it's still pertinent.

After some discussions with Peppers, we thought of a reason to have per-RID binaries: ReadyToRun places native code within the assembly, and we may want to provide ReadyToRun images within Java.Interop.dll and Mono.Android.dll to assist app startup times even in Debug configurations.

Meaning we probably will want per-RID copies of assemblies.

What needs exploration is whether each separate supported runtime will require different per-RID assemblies. If we assume builds of Mono.Android.dll for android-arm, android-arm64, android-x86, android-x64, and that each such build contains a ReadyToRun image, can that same binary assembly used by all of MonoVM, CoreCLR, and NativeAOT? If yes, then we can continue to ship 5 copies, and not (4 {RIDs} * 3 {runtimes})+1 = 13 copies.