[Android] Rename System.Security.Cryptography.Native.OpenSsl on Android

[tqiu8]

Rename System.Security.Cryptography.Native.OpenSsl to System.Security.Cryptography.Native.Android
Fix #52327

[ghost]

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Rename System.Security.Cryptography.Native.OpenSsl to System.Security.Cryptography.Native.Android
Fix #52327

Author:	tqiu8
Assignees:	-
Labels:	area-Infrastructure-mono
Milestone:	-

[filipnavara]

Most of the places should actually remain unchanged since they reference the real OpenSSL shim library and not the Android one.

[akoeplinger]

Looks good apart from two comments

[akoeplinger]

There are quite a lot of test failures with System.DllNotFoundException : libSystem.Security.Cryptography.Native.OpenSsl on the runtime-staging Android legs, e.g.

   at System.PlatformDetection.GetAlpnSupport() in /_/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.cs:line 162
   at System.Lazy`1[[System.Boolean, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].ViaFactory(LazyThreadSafetyMode mode) in System.Private.CoreLib.dll:token 0x6000fc6+0x43
   at System.Lazy`1[[System.Boolean, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor) in System.Private.CoreLib.dll:token 0x6000fc7+0x22
   at System.Lazy`1[[System.Boolean, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].CreateValue() in System.Private.CoreLib.dll:token 0x6000fcc+0x74
   at System.Lazy`1[[System.Boolean, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].get_Value() in System.Private.CoreLib.dll:token 0x6000fd2+0xa
   at System.PlatformDetection.get_SupportsAlpn() in /_/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.cs:line 168
   at System.Net.Test.Common.GenericLoopbackOptions..ctor() in /_/src/libraries/Common/tests/System/Net/Http/GenericLoopbackServer.cs:line 96
   at System.Net.Test.Common.LoopbackServer.Options..ctor() in /_/src/libraries/Common/tests/System/Net/Http/LoopbackServer.cs:line 384
   at System.Net.Test.Common.LoopbackServer..ctor(Options options) in /_/src/libraries/Common/tests/System/Net/Http/LoopbackServer.cs:line 29
   at System.Net.Test.Common.LoopbackServer.CreateServerAsync(Func`2 funcAsync, Options options) in /_/src/libraries/Common/tests/System/Net/Http/LoopbackServer.cs:line 70
   at System.Net.Tests.WebClientTestBase.DownloadFile_Success() in /_/src/libraries/System.Net.WebClient/tests/WebClientTest.cs:line 583
--- End of stack trace from previous location ---

This is because we include the Unix/OpenSSL version of Interop.CryptoNative.cs which has the wrong library name.

I think we should rename the CryptoNative field to AndroidCryptoNative for all the DllImports to AndroidCryptoNative_ functions to make these mistakes easier to catch.

[tqiu8]

This is because we include the Unix/OpenSSL version of Interop.CryptoNative.cs which has the wrong library name.

I think we should rename the CryptoNative field to AndroidCryptoNative for all the DllImports to AndroidCryptoNative_ functions to make these mistakes easier to catch.

That was one of my original approaches, but Android still uses several Interop files in the src/libraries/Common/src/Interop/Unix directory (Dllimports into CryptoNative_), which would require splitting those files into the src/libraries/Common/src/Interop/Android directory as well, thus creating duplicate files. Renaming CryptoNative is more efficient in that it takes advantage of shared entrypoint names but is definitely more ambiguous and harder to catch. I suppose in the long run it's better to make the split between Android and Unix more distinct?

/cc @steveisok

[marek-safar]

Can this be merged now?

[filipnavara]

Can this be merged now?

I believe it is still broken and references a wrong name of the library in some of the managed code (per comments above and Helix results in the runtime-staging pipelines).

[tqiu8]

From what I can tell, test failures are seemingly unrelated, re-running some of the failing lanes in case some of them were flakey.

[filipnavara]

FWIW it looks good to me. It would likely make sense to rename OpenSslCryptographicException to something Android specific but I don't think it's worth to hold up the PR because of it. It's a small detail and this PR would unblock any potential fixes of the name on the Xamarin side.

[steveisok]

@tqiu8 It looks like you're hitting known flakes. The android arm64 failures are being tracked in dotnet/xharness#597 and the Android x86 failure is hitting #52649

[steveisok]

/cc @grendello