[TrimmableTypeMap] Remove ForceUnconditionalEntries workaround

[simonrozsival]

Summary

Remove the ForceUnconditionalEntries workaround from the trimmable typemap generator and fix the underlying runtime type resolution gap that it was masking.

Background

ForceUnconditionalEntries was a temporary workaround for dotnet/runtime#127004 that forced all TypeMap entries to be emitted as 2-arg (unconditional), preventing the trimmer from removing unused framework bindings. Removing it restores 3-arg conditional entries, enabling proper trimming of unused MCW bindings.

The problem it was masking

With conditional entries enabled, TrustManagerFactory.GetTrustManagers() started returning ITrustManagerInvoker instead of IX509TrustManagerInvoker in the trimmable typemap path, causing 5 SSL ServerCertificateCustomValidationCallback tests to fail.

Root cause: Both the llvm-ir and trimmable typemap runtimes resolve Java objects to managed types by walking the Java class hierarchy via getSuperclass() — neither checks Java interfaces. The concrete trust manager's class hierarchy is:

TrustManagerImpl → X509ExtendedTrustManager (class) → Object

The llvm-ir path works because its custom trimming preserves javax/net/ssl/X509ExtendedTrustManager (a Java class in the hierarchy). When the hierarchy walk encounters it, it resolves to X509ExtendedTrustManagerInvoker which implements IX509TrustManager.

The trimmable path's ILLink-based trimming removes X509ExtendedTrustManager because nothing in managed code references it. This creates a gap: the hierarchy walk goes from the vendor class directly to java/lang/Object without finding a match. The javax/net/ssl/X509TrustManager TypeMap entry IS preserved (because isinst IX509TrustManager in FindX509TrustManager keeps it alive), but it's unreachable — getSuperclass() never returns interfaces.

The fallback TryGetProxyFromTargetType looks up typeof(ITrustManager) (the array element type requested by the marshalling code), which creates ITrustManagerInvoker — and is IX509TrustManager fails.

The fix

Add a Java interface walk fallback to TryGetProxyFromHierarchy. When targetType is an interface, at each level of the getSuperclass() walk, also check the Java interfaces via Java.Lang.Class.GetInterfaces() (which handles method ID caching and JNI remapping internally). Since getInterfaces() only returns directly declared interfaces (not transitive), we recurse into super-interfaces. All Java.Lang.Class wrappers and interface array elements are properly disposed to avoid gref leaks.

This gives the trimmable path the same resolution power that llvm-ir gets implicitly via its preserved class entries. See #11386 for longer-term investigation of interface-based TypeMap resolution.

Other changes

• Remove the ForceUnconditionalEntries constant and all conditional logic gated on it
• Restore 3-arg conditional TypeMapAttribute entries for non-essential MCW bindings
• Keep the [DynamicDependency] attributes on FindX509TrustManager — they're needed by both typemap paths to keep the invoker types alive (confirmed: removing them breaks llvm-ir too)
• Remove the obsolete API 21-23 Conscrypt TrustManagerImpl workaround (min API is now higher)
• Rename generated enum from AppFunctionState to AppFunctionEnabledState to fix name collision with Android API 37 android.app.appfunctions.AppFunctionState class
• Update typemap model and PE blob tests for restored conditional entry behavior
• Add device test TrustManagerFactory_GetTrustManagers_ReturnsIX509TrustManager that runs on both typemap paths
• Add unit tests for alias group base entry conditionality (all-MCW, mixed ACW/MCW, essential types)

Validation

• All 932 Release/CoreCLR/Trimmable Mono.Android.NET-Tests passed on device (0 failures)
• All 318 Release/CoreCLR/LlvmIr Mono.Android.NET-Tests passed on device (0 failures)
• All SSL ServerCertificateCustomValidationCallback_* tests pass on both paths
• New TrustManagerFactory_GetTrustManagers_ReturnsIX509TrustManager test passes on both paths
• Standalone typemap unit tests pass

[Copilot]

Pull request overview

This PR removes the ForceUnconditionalEntries workaround from trimmable typemap model generation, restoring conditional 3-arg TypeMapAttribute emission for non-essential MCW bindings while keeping essential runtime/user ACW entries unconditional.

Changes:

• Removes the global force-unconditional switch from ModelBuilder.
• Restores conditional target references for non-essential MCW entries.
• Updates model and PE blob tests to expect restored 3-arg behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Microsoft.Android.Sdk.TrimmableTypeMap/Generator/ModelBuilder.cs	Removes workaround logic and reverts unconditional decisions to IsUnconditionalEntry() plus alias-specific rules.
tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests/Generator/TypeMapModelBuilderTests.cs	Updates assertions and test names/comments for restored conditional MCW typemap entries.