[Trimming] Put HttpMessageHandler type resolution behind feature switch

[Copilot]

AndroidHttpClientHandlerType and XA_HTTP_CLIENT_HANDLER_TYPE rely on runtime type resolution via Type.GetType(), which is incompatible with trimming and NativeAOT. This PR disables this feature by default and adds deprecation warnings.

Changes

Runtime

• Add XaHttpClientHandlerType feature switch to RuntimeFeature.cs (disabled by default)
• When disabled, GetHttpMessageHandler() returns AndroidMessageHandler directly—no reflection
• Legacy behavior preserved when switch is enabled via _AndroidUseXaHttpClientHandlerType

Build-time validation

• XA1042 (error): NativeAOT + AndroidHttpClientHandlerType set → build fails
• XA1043 (warning): MonoVM/CoreCLR + AndroidHttpClientHandlerType set → deprecation warning
• XA1044 (warning): XA_HTTP_CLIENT_HANDLER_TYPE found in @(AndroidEnvironment) files

Property defaults

• Removed default value for $(AndroidHttpClientHandlerType) in DefaultProperties.targets

Migration

Pass custom handlers via constructor instead of MSBuild property:

var client = new HttpClient(new MyCustomHandler());

Documentation

Added docs for XA1042, XA1043, XA1044.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Trimming] Put code for resolving HttpMessageHandler type name behind feature switch</issue_title>
<issue_description>### Android framework version

net11.0-android (Preview)

Affected platform version

.NET 11

Description

We support passing the HTTP message handler type name via the AndroidHttpClientHandlerType or the XA_HTTP_CLIENT_HANDLER_TYPE environment variable. This is not compatible with trimming by default and while we can make sure this type is preserved by ILLink via custom trimmer steps, there is no reasonable way to do this for NativeAOT.

I suggest disabling the handler type lookup via XA_HTTP_CLIENT_HANDLER_TYPE env variable by default and introducing a feature switch to re-enable this feature. The GetHttpMessageHandler() method would simply return an instance of AndroidMessageHandler by default.

Steps to Reproduce

1. Set AndroidHttpClientHandlerType to an assembly qualified type name
2. This should not take precedence over UseNativeHttpHandler

Did you find any workaround?

No response

Relevant log output

```</issue_description>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes [Trimming] Put code for resolving HttpMessageHandler type name behind feature switch #10743

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[jonathanpeppers]

@simonrozsival can we use the existing feature switch, and we don't need a new one?

• https://github.com/dotnet/runtime/blob/133600318350fb9218881de2f6ef068f817b8317/src/libraries/System.Net.Http/src/System/Net/Http/HttpClientHandler.AnyMobile.cs#L793-L796

We'd duplicate it in this file like we did StartupHookProvider.IsSupported.

[simonrozsival]

So to use $(AndroidHttpClientHandlerType), devs would have to set $(UseNativeHttpHandler) to false? The UseNativeHttpHandler switch should mean true -> AndroidMessageHandler, false -> SocketsHttpHandler. I would prefer to keep those feature switches separate.

[jonathanpeppers]

Ok, I see, so the problem is we have a property you can set the type name. This is really a different feature than UseNativeHttpHandler=true/false.

I would be in favor of considering removal, when I look at the projects using it, they are Xamarin.Android:

• https://github.com/search?q=AndroidHttpClientHandlerType&type=code

[simonrozsival]

So you would straight up remove it and give a warning, instead of allowing to still opt-into it via a feature switch?

[jonathanpeppers]

Yes, I think we should warn if you use it on release/10.0.1xx branch.

Then main we upgrade warning to an error, and just remove the feature.