[trimming] preserve custom views and $(AndroidHttpClientHandlerType)

[jonathanpeppers]

Fixes: #8797

Here are two cases TrimMode=full can break applications:

• $(AndroidHttpClientHandlerType) set to a custom type

• Custom views (Android .xml) that are not referenced in C# code

In the MarkJavaObjects trimmer step we can preserve both of these cases by:

• Passing in $(AndroidHttpClientHandlerType), preserve the public, parameterless constructor of the type

• Pass in $(_CustomViewMapFile), preserve IJavaObject types if they are found in the map file

[jonathanpeppers]

The point of this, is we don't want to iterate over every type in every assembly.

Is Android.Util.IAttributeSet required for any custom view?

https://github.com/xamarin/xamarin-android/blob/14b70ac32b2a9efefae127795e96ef73124c8557/tests/Mono.Android-Tests/Mono.Android-Test.Library/CustomTextView.cs#L9

[jonpryor]

See:

• https://stackoverflow.com/a/36342089/83444
• https://ataulm.com/2019/10/28/resolving-view-attributes.html

IAttributeSet is used so that the View can obtain any XML attributes specified on the view. The above stack overflow answer has a good example of this:

<com.anjithsasindran.RectangleView
    app:radiusDimen="5dp"
    app:rectangleBackground="@color/yellow"
    app:circleBackground="@color/green" />

The AttributeSet is how the RectangleView constructor would lookup the values for @app:radiusDimen, @app:rectangleBackground, and @app:circleBackground.

I believe, but cannot quickly verify, that the (Context, IAttributeSet) constructor is always used/preferred by Android.

[jonathanpeppers]

This was another problem, when we have a @(ProjectReference) to the class library containing Mono.Android_Test.Library -- there was no C# code using types from the library. And so the C# compiler would omit the assembly reference, and the trimmer did not even receive it as input.

[jonpryor]

Is this (still?) a problem? #8904 updated things to look for "transitive assembly references" (see also).

If we need to add explicit type references to work around missing transitive assembly references, maybe we need to revisit #8904?

[jonathanpeppers]

#8904 is unrelated.

The problem here is if you add a reference to a class library not using any types from it, and one of the AndroidResource .xml files uses a custom view. The C# compiler will ignore the assembly, but the AndroidResource files would still make it to the app.

I'm not sure if this would happen in practice/real customer projects.

[jonathanpeppers]

I filed this for the future, and put it in comments:

• Nothing preserves an assembly reference, if no C# types are used directly #9008

[dellis1972]

👍

[jonpryor]

Shouldn't we "register" mapFile? (And why didn't we do this before, given that the beginning of this method calls .GetRegisteredTaskObjectAssemblyLocal<…>(…)?)

var map  = LoadCustomViewMapFile (mapFile);
if (map != null) {
    engine.RegisterTaskObject (mapFile, map, RegisteredTaskObjectLifetime.Build, allowEarlyCollection: false);
}
return map;

[dellis1972]

The RegisterTaskObjectAssemblyLocall call happens inside LoadCustomViewMapFile see https://github.com/xamarin/xamarin-android/blob/a9706b6ef0429250ecaf1e500d77cd19e94e2eb5/src/Xamarin.Android.Build.Tasks/Utilities/MonoAndroidHelper.cs#L408

[dellis1972]

Oh the code changed... ah cos of the linker can't use RegisterTaskObject

[dellis1972]

Sorry just actually read your comment (its early). The Registration of the file happens in SaveCustomViewMapFile.

[jonathanpeppers]

Yeah, the new method that doesn't support RegisterTaskObject is for the linker/trimmer step assembly. It doesn't have access to MSBuild APIs.