Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TrustFailure exception with inner exception: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED on android and xamarin-forms on android #4688

Closed
xanderh opened this issue May 14, 2020 · 49 comments
Labels
Area: HTTP Issues with sockets / HttpClient.

Comments

@xanderh
Copy link

xanderh commented May 14, 2020

Steps to Reproduce

(See attached project)

  1. Click floating action button
  2. App will attempt to enroll on our servers 10 times
  3. App reports number of failures, and posts the exception to logcat

EnrollmentTest.zip

Expected Behavior

App successfully enrolls 10 times in a row, and reports no errors, every time.

Actual Behavior

App will somewhat consistently fail to enroll at first, but eventually succeed. The first attempt will almost always fail with a TrustFailure exception, but after a few tries will succeed.

The error started occurring this week out of nowhere. It's been happening to apps in development, but also published apps that haven't been updated since March.
Additionally, the error is only happening on Android, not on xamarin.iOS apps. We're seeing the issue on multiple versions of Android (confirmed on 4.4, 7.1, 8.1, and 9.0), and in apps made in xamarin.android and xamarin.forms.

The certificates for the server look fine at a glance, but I have attached the certs as they appear in logcat in case they're the problem. The certificates are the same, no matter if it succeeds or fails.

Version Information

Microsoft Visual Studio Community 2019
Version 16.5.4
VisualStudio.16.Release/16.5.4+30011.22
Microsoft .NET Framework
Version 4.8.03752

Installed Version: Community

Visual C++ 2019 00435-60000-00000-AA425
Microsoft Visual C++ 2019

ASP.NET and Web Tools 2019 16.5.236.49856
ASP.NET and Web Tools 2019

ASP.NET Web Frameworks and Tools 2019 16.5.236.49856
For additional information, visit https://www.asp.net/

Azure App Service Tools v3.0.0 16.5.236.49856
Azure App Service Tools v3.0.0

Azure Functions and Web Jobs Tools 16.5.236.49856
Azure Functions and Web Jobs Tools

C# Tools 3.5.0-beta4-20153-05+20b9af913f1b8ce0a62f72bea9e75e4aa3cf6b0e
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools 1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Extensibility Message Bus 1.2.0 (d16-2@8b56e20)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

IntelliCode Extension 1.0
IntelliCode Visual Studio Extension Detailed Info

Microsoft Azure Tools 2.9
Microsoft Azure Tools for Microsoft Visual Studio 2019 - v2.9.30207.1

Microsoft Continuous Delivery Tools for Visual Studio 0.4
Simplifying the configuration of Azure DevOps pipelines from within the Visual Studio IDE.

Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft Library Manager 2.1.25+gdacdb9b7a1
Install client-side libraries easily to any web project

Microsoft MI-Based Debugger 1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Microsoft Visual C++ Wizards 1.0
Microsoft Visual C++ Wizards

Microsoft Visual Studio Tools for Containers 1.1
Develop, run, validate your ASP.NET Core applications in the target environment. F5 your application directly into a container with debugging, or CTRL + F5 to edit & refresh your app without having to rebuild the container.

Microsoft Visual Studio VC Package 1.0
Microsoft Visual Studio VC Package

Mono Debugging for Visual Studio 16.5.514 (c4f36a9)
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager 5.5.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

ProjectServicesPackage Extension 1.0
ProjectServicesPackage Visual Studio Extension Detailed Info

SQL Server Data Tools 16.0.62003.05170
Microsoft SQL Server Data Tools

TypeScript Tools 16.0.20225.2001
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools 3.5.0-beta4-20153-05+20b9af913f1b8ce0a62f72bea9e75e4aa3cf6b0e
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools 10.8.0.0 for F# 4.7 16.5.0-beta.20181.6+85af456066acd4e76d2bc7821b44a325e46f2fca
Microsoft Visual F# Tools 10.8.0.0 for F# 4.7

Visual Studio Code Debug Adapter Host Package 1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

Visual Studio Container Tools Extensions (Preview) 1.0
View, manage, and diagnose containers within Visual Studio.

Visual Studio Tools for Containers 1.0
Visual Studio Tools for Containers

VisualStudio.DeviceLog 1.0
Information about my package

VisualStudio.Foo 1.0
Information about my package

VisualStudio.Mac 1.0
Mac Extension for Visual Studio

Xamarin 16.5.000.533 (d16-5@9152e1b)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer 16.5.0.470 (remotes/origin/d16-5@681de3fd6)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates 16.5.49 (0904f41)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK 10.2.0.100 (d16-5/988c811)
Xamarin.Android Reference Assemblies and MSBuild support.
Mono: c0c5c78
Java.Interop: xamarin/java.interop/d16-5@fc18c54
ProGuard: xamarin/proguard@905836d
SQLite: xamarin/sqlite@46204c4
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-5@9f4ed4b

Xamarin.iOS and Xamarin.Mac SDK 13.16.0.13 (b75deaf)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

Log File

cert logs.txt

Lastly, I apologize for not adding a label, I couldn't find a way to do so for some reason.

@radekdoulik
Copy link
Member

Looks like duplicate of #3682 (comment) and #3705

Please try to use the HttpClientHandler.ServerCertificateCustomValidationCallback

@xanderh
Copy link
Author

xanderh commented May 15, 2020

I'm not sure this is actually a duplicate of those issues. They seem to be about custom validation handlers not working. The problem is, we don't have any custom validation handlers for SSL certificates, the built-in one worked fine up until the start of this week. Additionally, the version that worked in 9.0 but not in 10.0 still works just fine for us.
On top of that, it started happening in apps that haven't been updated since March, but we didn't see any issues before Monday of this week.

If we add the following code, the issue stops happening:
System.Net.ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicy) => { return true; };
This is obviously bad practice as it completely bypasses any validation of the SSL certificate, opening us up to man-in-the-middle attacks. We could write our own code here, but it would likely not be as secure as something coming from Microsoft.

@radekdoulik
Copy link
Member

@baulig could you please take a look at this issue?

@grendello grendello added this to the Under Consideration milestone May 19, 2020
@grendello grendello added the Area: Mono Runtime Mono-related issues: BCL bugs, AOT issues, etc. label May 19, 2020
@Euler-KB
Copy link

Same issue here for Xamarin.Android apps built in March. Failing to connect backend

@Euler-KB
Copy link

Euler-KB commented May 30, 2020

Same issue here for Xamarin.Android apps built in March. Failing to connect backend

Ooops. Just found the cause. Was an issue with expired CA certificate (Issue might occur for all Positive SSL's purchased on Namecheap ) - Expiry date for CA cert was May 2020

https://www.namecheap.com/support/knowledgebase/article.aspx/9393/69/where-do-i-find-ssl-ca-bundle

@visuall
Copy link

visuall commented Jun 10, 2020

Similar issue with certs from Sectigo on Android when URL which uses the cert is hit - "https://xerxes-sub.xerxessecure.com" - with httpclient. At the same time it works on iOs and Windows. Chrome also works on Droid. It is just Xamarin failing on Droid.
If we ignore the error all works but this is not good solution at all. Debugging shows incorrect certificate chain built on Android based on the article with explanations what the chain should be: https://thesslonline.com/blog/sectigo-addtrust-external-ca-root-expiring-may-30-2020. When Xamarin is debugged on ios the cert chain is correct.

@derekwheeler-tylertech
Copy link

derekwheeler-tylertech commented Jun 25, 2020

I can confirm this is also happening with certs from Sectigo. Only on android. I also debugged the cert chain and confirmed it is terminating in the root cert "AddTrust External CA Root" that expired on 5/30/2020 rather than their cross-signed root cert "USERTrust RSA Certification Authority", (which does exist in my version of android). This article, https://www.cmu.edu/iso/service/cert-auth/addtrust.html suggests ssl client implementations based on OpenSSL v1.1.1 or before might have this issue. Is it possible the version of BoringSSL that Xamarin uses is based on an older OpenSSL fork? I would also point out that this is a serious problem that we can't fix via code, short of disabling all SSL certificate validation, which obviously we can't do. This is currently affecting at least one of our clients (an entire large US city government). Thanks

@visuall
Copy link

visuall commented Jun 26, 2020

I have been able to go around this by using the native Android http handler - AndroidClientHandler. It is properly validating the certificate in such case.

@derekwheeler-tylertech
Copy link

Thanks @visuall . I tried that and still have the problem. I did a clean/rebuild, uninstalled the app, and rebooted the phone. But I appreciate the suggestion!
I was able to find a not-so-great solution. In the phone, if I disable the now expired "AddTrust External CA Root" root cert the problem is fixed. The problem with this solution is trying to get this information to the end users. The way to set this in the phone Settings is different in each android version and also differs from phone vendor to vendor.

@skacofonix
Copy link

I encountered a similar problem with Sectigo CA root expiration.
As @visuall say, i changed the implementation of HTTP handler from managed to Android.
This perfectly solved the problem for me


Implementation before
Fail to validate certificate chain with expired Sectigo cert.

public class HttpClientProvider
{
    public HttpClient Get()
    {
        return new HttpClient(new HttpClientHandler());    // Use legacy managed implementation
    }
}

Implementation after (Forms side)
Successfully validates the flawed certificate chain

public class HttpClientProvider
{
	public HttpClient Get()
	{
		var nativeHttpMessageHandler = DependencyService.Get<INativeHttpMessageHandlerProvider>().Get();
		return new HttpClient(nativeHttpMessageHandler);    // nativeHttpMessageHander is injected from Android project
	}
}
public interface INativeHttpMessageHandlerProvider
{
	HttpMessageHandler Get();
}

Implementation after (Android side)
Don't forget to add dependency System.Net.Http from NuGet

[assembly: Dependency(typeof(AndroidHttpMessageHandlerProvider))]
namespace SmartConnect.Droid.PlatformSpecific
{
    public class AndroidHttpMessageHandlerProvider : INativeHttpMessageHandlerProvider
    {
        public HttpMessageHandler Get()
        {
            return new AndroidClientHandler();
        }
    }
}

@derekwheeler-tylertech
Copy link

derekwheeler-tylertech commented Jul 15, 2020

Thanks @skacofonix for those details.

For the xamarin team:

I think my problem is that I'm using the SOAP classes that the wsdl tool, (i.e. Web References->Add Web Reference), spits out in visual studio, It's not clear to me whether those use the HttpClient internally or something else. An example class that gets produced is:

//
// This source code was auto-generated by Microsoft.VSDesigner, Version 4.0.30319.42000.
//

public partial class MyExampleService : System.Web.Services.Protocols.SoapHttpClientProtocol { }

I had set the HttpClient to Android in the build settings, (https://docs.microsoft.com/en-us/xamarin/android/app-fundamentals/http-stack?tabs=windows), thinking that that setting would be used by these SOAP classes but I guess that was wishful thinking?

Thanks

@gerricom
Copy link

Hello everybody. I came across this problem today when the DST Root CA X3 expired earlier this day. Our Xamarin App on Android stopped working with the exact inner exception mentioned above. This CA was longtime used with let's encrypt certificates which we are using for our service.

Chrome and other browsers on Android had no problem in opening websites from on of our servers but the Xamarin app has. I renewed our current certificate and switched to the ISRG Root X2 chain which is not terminating in a DST Root but this had no impact.

I switched from the managed HTTPClient to the Android option but this has not changed the behavior either.

Our current workaround is to not use LE for our certificates, but I'm not absolutely happy with that. So can somebody explain, why this is a problem? Am I doing something wrong? I guess that there must be others using Let's Encrypt with their Xamarin Apps and I guess they are in kind of trouble too? Or is it just us...?

@cvb941
Copy link

cvb941 commented Sep 30, 2021

Can confirm we have the same problem. We switched from a Sectigo certificate that ceased to work last week to Caddy which uses Let's Encrypt certificates, and today that one stopped working too 😐.

I will try the switch to the AndroidClientHandler to see if it changes something.

@gerricom
Copy link

This is also reported in #6351.

@cvb941
Copy link

cvb941 commented Sep 30, 2021

We fixed it by using ZeroSSL instead of Let's Encrypt. ZeroSSL uses acme too, so it is just a drop-in replacement.

Here's how to set it up with Caddy https://caddy.community/t/using-zerossls-acme-endpoint/9406

Using AndroidClientHandler did not work.

@angelru
Copy link

angelru commented Sep 30, 2021

any solution??

@stereoa
Copy link

stereoa commented Oct 1, 2021

Also seeing this issue today.

@darrenctlo
Copy link

I have seen this with an app talking to an Akamai fronted service (uses LetsEncrypt for SSL certs).

You'll need to do two things:

1] Update your code to use AndroidClientHandler (long term belt & braces solution)
2] Update the trust chain for the SSL certificates on the server you're attempting to talk to (immediate fix)

Thanks to @skacofonix for the solution posted above.

@angelru
Copy link

angelru commented Oct 1, 2021

I use refit to access the api and the implementation is in Android

@Martinn2
Copy link

Martinn2 commented Oct 1, 2021

The same issue with new lets encrypt root cert !

@uzairali001
Copy link

I'm was also having the same issue but after some research trials and errors I found out the solution well it's more like a workaround.
The root certificate of Let's encrypt is expired so just remove it from the yourcert-chain.prem.

  • Open the file in any text editor
  • Locate the last -----BEGIN CERTIFICATE----- at the end of the file
  • Delete it from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE-----
  • Save and reload the nginx

@daltonks
Copy link

daltonks commented Oct 1, 2021

How to fix this when you generate new certs can be found at #6351 (comment)

@kapsiR
Copy link

kapsiR commented Oct 1, 2021

I can confirm this issue with the expiration of the DST Root CA X3, which is still used for cross-signing ISRG Root X1.

An immediate fix on the server side is to force the ISRG Root X1.
e.g. with Certbot certbot renew --force-renewal --preferred-chain "ISRG Root X1"

[Update]
Don't forget to reload the web servers to apply the new certificate
@daltonks was a bit faster 😉

@lafin716
Copy link

lafin716 commented Oct 1, 2021

How to fix this when you generate new certs can be found at #6351 (comment)

@uzairali001 This is perfect answer for our services. even if generate new certs with ISRG ROOT X1
but somehow there is legacy keychain data in .pem files so we removed it and reload the servere and it worked in xamarin-android

@agusibrahim
Copy link

its totaly break my apps with 1k active customer.
i was change httpclient impl to android and ssl to native. its doesnt work
anyone pls help

@uzairali001
Copy link

its totaly break my apps with 1k active customer. i was change httpclient impl to android and ssl to native. its doesnt work anyone pls help

You can try workaround I've posted #4688 (comment)

@agusibrahim
Copy link

its totaly break my apps with 1k active customer. i was change httpclient impl to android and ssl to native. its doesnt work anyone pls help

You can try workaround I've posted #4688 (comment)

thnx, i was handle in client app.
Issue is solved 🎉 thnx to all
i using custom httpclienthandler for logging purpose, without me knowing, it ignore the androidclienthandler that I have selected in the android project options.

@angelru
Copy link

angelru commented Oct 3, 2021

How is it possible that a call from flutter works and xamarin doesn't? this makes me rethink many things ...

@uzairali001
Copy link

How is it possible that a call from flutter works and xamarin doesn't? this makes me rethink many things ...

Probably because Xamarin doesn't have any update in last 6 months they are focusing on Maui

@juwens
Copy link

juwens commented Nov 26, 2021

How is it possible that a call from flutter works and xamarin doesn't? this makes me rethink many things ...

Probably because Xamarin doesn't have any update in last 6 months they are focusing on Maui

@jfversluis for your attention

@jfversluis
Copy link
Member

@juwens thanks for the ping!

@angelru

How is it possible that a call from flutter works and xamarin doesn't? this makes me rethink many things ...

Very simple, they work on a different tech stack and one has a bug right now. Not sure what comparing these two products, or this comments as a whole adds to this discussion to be honest. If you are considering changing careers, you're more than welcome to do so but please don't disrupt an otherwise constructive conversation.

@uzairali001

Probably because Xamarin doesn't have any update in last 6 months they are focusing on Maui

I understand that you're frustrated with this bug, I'm sorry about that. However this seems to be a bug in the mono runtime. That team is pretty far from the .NET MAUI team and has nothing to do with each other in terms of what is keeping us busy right now. And right now you are looking at the Xamarin.Android repo, which is still not the .NET MAUI team. Lastly, not having updates for 6 months is simply not true, but I get that it could be perceived as weird that we're focussing on the next thing while you have issues with the current thing.

Like above, I also don't see what this adds to the conversation here.

Please try to not derail this issue (or any issue) with things like these because not only will it not speed up fixing these bugs, it will also make people working hard on this feel bad, and potentially makes you look like a not so nice person to others on the internet.

If you have any complaints or remarks, feel free to find my email address on my GitHub profile so we can have a chat or I can put you in touch with the right person.

Unfortunately, I don't know anything about this bug so I can't add anything of value there.

@juwens
Copy link

juwens commented Nov 26, 2021

@jfversluis as a dev on the team, i think it's a bad idea to write 18! months after the bug was created, and several people posting here too, that nothing can be done, because you work on MAUI and "it's not a XF bug", and the author should create an issue for the mono runtime.

1. you cannot ignore bugs of a production release, with the argument that you are working on the next version
2. if it's a problem of the mono runtime, it should have been redirected by an MS employee, when you triaged it back in may 2020

image

These things is what makes people more and more aggressive in there communication.

Complaining about severe nuisances (without any insight of the XF team) is the last resort devs have, before giving up and turning away from XF and moving to a competitor like Flutter.

//cc @maddymontaquila

@jfversluis
Copy link
Member

jfversluis commented Nov 29, 2021

This is the last thing I will post about it here or anywhere, because this is still derailing this issue. As already mentioned: if you have something to see do it on an appropriate channel like a discussion. I am also kind of disappointed that I spend a lot of time talking to you about this @juwens and you still choose this approach.

  1. you cannot ignore bugs of a production release, with the argument that you are working on the next version

I'm sorry you understood it this way, but that is not what I said nor meant.

  1. if it's a problem of the mono runtime, it should have been redirected by an MS employee, when you triaged it back in may 2020

As already pointed out, there is a bug for this on the Mono repo, so if anything this should've been probably closed. But as I am not on this team, do not have any insights on how they work nor do I have even any rights to do anything on this repo, that is up to them.

These things is what makes people more and more aggressive in there communication.

Aggression is never the answer. If you are frustrated with something and you think Xamarin is no longer the right option for you, that is of course not what we want. But being bitter on the internet is never a good look on anyone.

@juwens
Copy link

juwens commented Jan 4, 2022

@radekdoulik
this is still an issue

@lmataf
Copy link

lmataf commented Jan 20, 2022

image
Solucionado en Visual Studio

@marek-safar
Copy link
Contributor

@steveisok please take a look

@naman20sharma
Copy link

Thanks @skacofonix for those details.

For the xamarin team:

I think my problem is that I'm using the SOAP classes that the wsdl tool, (i.e. Web References->Add Web Reference), spits out in visual studio, It's not clear to me whether those use the HttpClient internally or something else. An example class that gets produced is:

// // This source code was auto-generated by Microsoft.VSDesigner, Version 4.0.30319.42000. // public partial class MyExampleService : System.Web.Services.Protocols.SoapHttpClientProtocol { }

I had set the HttpClient to Android in the build settings, (https://docs.microsoft.com/en-us/xamarin/android/app-fundamentals/http-stack?tabs=windows), thinking that that setting would be used by these SOAP classes but I guess that was wishful thinking?

Thanks

Hi Could you please help how were you able resolve this issue ? I am facing similar one as the we application is using Cert from Secticgo, and I am using an sdk that is internally using HttpClient.

@derekwheeler-tylertech
Copy link

derekwheeler-tylertech commented Feb 16, 2022

Sorry @naman20sharma. We never got any support on fixing this bug. We ended up giving instructions to the android users to delete the expired root cert (see my other earlier posts) so that the cert chain ended up finding the valid root cert. A terrible solution. This bug caused the app to be broken for hundreds of our government app users.

@nikola43
Copy link

I'm was also having the same issue but after some research trials and errors I found out the solution well it's more like a workaround. The root certificate of Let's encrypt is expired so just remove it from the yourcert-chain.prem.

  • Open the file in any text editor
  • Locate the last -----BEGIN CERTIFICATE----- at the end of the file
  • Delete it from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE-----
  • Save and reload the nginx

works for me

@jpobst jpobst added Area: HTTP Issues with sockets / HttpClient. and removed Area: Mono Runtime Mono-related issues: BCL bugs, AOT issues, etc. labels Sep 6, 2022
@Meekohi
Copy link

Meekohi commented Oct 20, 2022

Appears to still be an issue - cert is valid in e.g. Chrome but am getting Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED when trying to make a call from a Xamarin app on Android.

I worked around this by creating a custom https handler for the specific domain I was having an issue with (only used in local testing for us):

private HttpClient CreateHttpClient()
{
    if (Common.Helpers.EnvironmentVariables.APIPath.Contains("ngrok"))
    {
        var httpClientHandler = new HttpClientHandler();
        httpClientHandler.ServerCertificateCustomValidationCallback = (msg, cert, chain, errors) => { return true; }; // Ignore SSL errors for local development
        return new HttpClient(httpClientHandler);
    }
    return new HttpClient();
}

@awesome1128
Copy link

awesome1128 commented Feb 15, 2023

I'm was also having the same issue but after some research trials and errors I found out the solution well it's more like a workaround. The root certificate of Let's encrypt is expired so just remove it from the yourcert-chain.prem.

  • Open the file in any text editor
  • Locate the last -----BEGIN CERTIFICATE----- at the end of the file
  • Delete it from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE-----
  • Save and reload the nginx

What do you mean by "yourcert-chain.prem"?
I have cert.pem, chain.pem, fullchain.pem and privkey.pem files only. No any file that file extension is .prem
I deleted last -----BEGIN CERTIFICATE----- at the end of the file from fullchain.pem file.
Also , I ran certbot renew --force-renewal --preferred-chain "ISRG Root X1" command as well.

Is that correct?

I have xamarin project, but I don't know well xamarin.
I am using visual studio 2019 and it's configured with remote server, but I keep getting "System.Exception: 'Something went wrong with cert validation" error.
I am spending much time to fix this problem, but no idea.

Please let me know your thoughts, thanks!

@ajpinedam
Copy link

This is still a problem. Using Refit.

Using AndroidClientHandler didn't work.

Our current configuration is:

image

@jpobst
Copy link
Contributor

jpobst commented May 13, 2024

With support for Classic Xamarin.Android ended May 1st, 2024, this issue is likely no longer relevant.

If this still persists in .NET 8+, please open a new issue with updated information based on net8.0-android or greater. Please include a link to this issue for context.

@jpobst jpobst closed this as not planned Won't fix, can't repro, duplicate, stale May 13, 2024
@derekwheeler-tylertech
Copy link

This was one of the final straws that made us decide to abandon the Microsoft mobile tech stack. We had apps in the field with thousands of corporate users that were affected by this bug. There was no work around. As a Microsoft Partner that was hard to swallow.

@juwens
Copy link

juwens commented May 21, 2024

This is hilarious, despite the name change from Xamarin.Android to .Net for Android, this repository is exactly the same as before. Even the target files provided by “.Net for Android” are still the same “xamarin.android….target”

But this ticket “obviously” needed to be closed, cause the issue is with Xamarin.Android.

'If you encouter a “similar” issue in the latest version of maui, please open a new ticket for “.Net for Android” in the same repository, which was formerly named “Xamarin.Android”'
😉

@jpobst
Copy link
Contributor

jpobst commented May 21, 2024

While they certainly share a good amount of code, two of the biggest changes between Xamarin.Android and .NET for Android are:

  • .NET for Android now uses the exact same Base Class Libraries (BCL) as desktop .NET instead of Mono's BCL clone used by Xamarin.Android.
  • The Android integration HTTP stack was completely rewritten.

These two changes should eliminate a large class of bugs that occurred on Xamarin.Android.

@github-actions github-actions bot locked and limited conversation to collaborators Jun 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Area: HTTP Issues with sockets / HttpClient.
Projects
None yet
Development

No branches or pull requests