Feature Request: Change the Default HttpClient Implementation to AndroidClientHandler, instead of HttpClientHandler

[TheCodeTraveler]

Feature Request: Change the default HttpClient Implementation to use AndroidClientHandler

The default HttpClient Implementation today is HttpClientHandler.

[JonDouglas]

Our default is still managed here via System.Net.Http.HttpClientHandler:

https://github.com/xamarin/xamarin-android/blob/master/src/Xamarin.Android.Build.Tasks/Tasks/BuildApk.cs#L367

This seems reasonable to update to AndroidClientHandler as the default via the Cloud note in our docs:

April, 2018 – Due to increased security requirements, including PCI compliance, major cloud providers and web servers are expected to stop supporting TLS versions older than 1.2. Xamarin projects created in previous versions of Visual Studio default to use older versions of TLS.

In order to ensure your apps continue to work with these servers and services, you should update your Xamarin projects with the Android HttpClient and Native TLS 1.2 settings shown below, then re-build and re-deploy your apps to your users.

Are there any concerns surrounding this change @jonpryor @pjcollins ? We can outline this change in our release notes with a note on how to revert as well.

[pjcollins]

@JonDouglas I think we'd want to do some explicit acceptance testing before flipping this switch, though I can't immediately think of any concerns or reason why this wouldn't work. On the other hand, with BTLS now enabled by default in the VS 15.7 release, I don't see the need for the default HttpClient implementation to change. The current default (Managed) HttpClient implementation now supports TLS 1.2, which should address the security concern listed above [0]. Users are not required to enable both options to bring TLS 1.2 support to a Xamarin.Android application by my understanding, but should instead select one option or the other based on what suits them best.

@jonpryor is my understanding here more or less correct? What are your thoughts?

[0] April, 2018 – Due to increased security requirements, including PCI compliance, major cloud providers and web servers are expected to stop supporting TLS versions older than 1.2

Edit - we may want to consider rewording some of the documentation here to better reflect the recent default TLS provider change, as there appears to be some somewhat contradictory information around the "Managed (HttpClientHandler)" HttpClient implementation which is another potential point of confusion.

[JonDouglas]

@pjcollins Agreed. My main concern was keeping up with the best practices our docs outline which we recommend to use AndroidClientHandler which we currently don't set by default. Specifically:

In order to ensure your apps continue to work with these servers and services, you should update your Xamarin projects with the Android HttpClient and Native TLS 1.2 settings shown below, then re-build and re-deploy your apps to your users.

and

AndroidClientHandler is the new handler that delegates to native Java/OS code instead of implementing everything in managed code. This is the recommended option.

Given that the managed handler is considered "old" and the native handler is considered "new" this seems like an ideal change for various benefits(native performance, smaller executable, etc) that outweigh the cons.

I think another question is whether we should default users to a minSdkVersion of API 21 or API 14 as AndroidClientHandler will require API 21. The current minSdkVersion for modern Android Developers is 21. This would change the workflow to be reversed if users want to support devices < API 21 as they would have to then change the handler to managed.

Obligitory Tweet on minSdkVersion:

https://twitter.com/minSdkVersion/status/988538738639765505

[pjcollins]

Sorry if I didn't come across entirely clearly, the point I was trying to make is that I don't think it necessarily makes sense for a user to want to enable both the Android HttpClient implementation and BTLS as their TLS provider. I think that the concept of "managed" being "old" and "native" being "new" is also a bit of a misconception now that the managed HttpClient uses a new implementation of BTLS by default.

As far as the suggested benefits of enabling the Android HttpClient implementation by default are concerned, I have a couple of comments/questions:

1. Users won't see the .apk size reduction if we only change the default HttpClient implementation, as BTLS will still be enabled by default and bring in it's dependencies. BTLS can be disabled, but this may not be intuitive.
2. Do we have benchmarks which show that the Android HttpClient implementation is more performant than the managed HttpClient implementation w/ BTLS?

[jonpryor]

Why do you want to change the default HttpClient Implementation to AndroidClientHandler instead of HttpClientHandler?

Presumably the answer is "TLS 1.2 support".

We have two ways of providing TLS 1.2 support:

1. BTLS, via $(AndroidTlsProvider)=btls or $(AndroidTlsProvider)="" (the current default since d15-7)
2. AndroidClientHandler.

BTLS works on all Android versions, but requires adding libmono-btls-shared.so to the .apk for all selected ABIs. It thus increases the minimum app size.

AndroidClientHandler avoids the size increase brought on by BTLS, but at an unknown cost: It won't provide TLS 1.2 support when running on Android < 5.0.

As per the current Distribution Dashboard (2018-05-29), KitKat and older make up ~15.3% of all devices which "visited the Google Play Store in the prior 7 days."

If we use AndroidClientHandler and disable BTLS support, 15% of a "current" user base won't be able to access TLS 1.2 resources. Is that desirable?

The "alternative" of enabling AndroidClientHandler and also enabling BTLS isn't actually an alternative: when using HttpClient, AndroidClientHandler supersedes BTLS. If you have both present, then default new HttpClient() behavior is to use AndroidClientHandler, the end. Which still means that ~15% of the current user base can't access TLS 1.2 resources.

For defaults, we need an option which we believe will cover the most user cases with the fewest number of changes. I do not currently see AndroidClientHandler-as-default doing that.

[zwaap]

AndroidClientHandler avoids the size increase brought on by BTLS, but at an unknown cost: It won't provide TLS 1.2 support when running on Android < 5.0

The lower bound for TLS 1.2 support is now API 16 since this PR, right? The Distribution Dashboard shows usage of < API 16 at 0.5% (as of 2018-10-26). Might it make sense to change the default now?

[jpobst]

It looks like we made this the default in our New Project templates at some point:

<AndroidHttpClientHandlerType>Xamarin.Android.Net.AndroidClientHandler</AndroidHttpClientHandlerType>

Additionally this has been completely changed for Xamarin - NET 6, so it is a moot point for NET 6.