[trimming] mark Java objects as "instantiated"

[jonathanpeppers]

Fixes: #9399

The .NET trimmer will inline cast statements such as:

var d = Application.Context.Resources.GetDrawable (resId);
Assert.IsNotNull (d as NinePatchDrawable);

If NinePatchDrawable is not "instantiated" anywhere via new(), inlined to:

var d = Application.Context.Resources.GetDrawable (resId);
Assert.IsNotNull (null); // BOOM!

We can solve this by:

1. MarkJavaObjects now inspects Mono.Android.dll

2. If we encounter an IJavaObject call:

Annotations.MarkInstantiated (type);

Since Java can create these objects, the most reasonable thing we can do is say that they are "instantiated". Hopefully, this still allows types to be trimmed away if they are completely unused. TBD.

Unfortunately, the MarkInstantiated() method is not public in ILLink's reference assembly, so I had to resort to calling it via System.Reflection.

TBD how much this affects app size, will find out what CI reports.

I also fixed the $(RuntimeIdentifiers) in TestApks.targets to check if someone passed -r android-arm64, for example.

[jonathanpeppers]

As expected, there is a size increase, but this might be reasonable.

[jonathanpeppers]

@sbomer @vitek-karas do you have any thoughts on this one?

This is mainly trying to avoid this optimization, if a type can be created from Java:

• https://github.com/dotnet/runtime/blob/270c2b13a047d90c2050911e1232e00f0e7511a4/src/tools/illink/src/linker/Linker.Steps/MarkStep.cs#L484

We currently don't have a way to know if Java will instantiate one of these types.

[sbomer]

Instead of reflecting over MarkInstantiated, I'd preserve the relevant constructors (like existing PreserveConstructors logic does) - that'll result in it being considered instantiated.

[sbomer]

In general, it looks like the existing logic was written to call PreserveJavaObjectImplementation on the relevant types - those that implement IJavaObject, and are a custom view or have IJniNameProviderAttribute. If this was missing some types, should the remaining logic from PreserveJavaObjectImplementation run for all IJavaObject-implementing types too?

[jonathanpeppers]

Seeing what happens to app size if we just call PreserveJavaObjectImplementation() on every type, but only mark in the two special cases.

[vitek-karas]

I'm probably missing some things, but in general:

• Marking things as instantiated on its own is wrong - there's no guarantee that the .ctor will be preserved - instead we should mark .ctor (or all .ctors if necessary) and that will mark the type as instantiated. (Technically we have to support types which are instantiated but without a .ctor, but I don't expect that to be used by the Java interop)

A general question - for types which can be instantiated via Java - I would think we have to assume they're going to be used, as there's nothing on the managed side which would tell us one way or another, so we have to preserve the type and its .ctors, right?

[jonathanpeppers]

A general question - for types which can be instantiated via Java - I would think we have to assume they're going to be used, as there's nothing on the managed side which would tell us one way or another, so we have to preserve the type and its .ctors, right?

Yes, that is where I'm at now, it looks like I can preserve the special constructor here:

android/src/Microsoft.Android.Sdk.ILLink/MarkJavaObjects.cs

Line 172 in 8667eba

void PreserveIntPtrConstructor (TypeDefinition type)

This ctor would always be called from Java.

[jonathanpeppers]

This might have gone too far, it made "hello world" grow a lot:

--  "PackageSize": 2865685
++  "PackageSize": 3213845

Going to try just the IntPtr constructor, which probably will end up where the original commit was.

[jonathanpeppers]

Closing in favor of #9435