[Android] Put Java JNI function in a separate static library #108513
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aa4fac2 to
7e67d99
Compare
|
Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger |
This was referenced Oct 3, 2024
c77e32e to
25d242e
Compare
In dotnet/android#9006 we are working on linking the .NET for Android runtime dynamically at the application build time. Linking involves all the BCL native libraries, including `System.Security.Cryptography.Native.Android` and one of the goals is to hide all the exported symbols used as p/invokes by the managed BCL libraries. This is because p/invoke calls are handled internally and, with dynamic linking of the runtime, there is no longer any reason to use `dlopen` and `dlsym` to look them up, they are all resolved internally, at the link time. Symbol hiding works fine thanks to the `--exclude-libs` `clang` flag, which makes all the exported symbols in the indicated `.a` archives to not be exported by the linker. However, `System.Security.Cryptography.Native.Android` is special in the sense that it contains one symbol which must not be hidden, `Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate`. The above function is a Java `native` method implementation, and it requires that not only its name follows the Java JNI naming rules, but that is also available for the JVM to look up using `dlsym`. I tried using the `--export-dynamic-symbol` clang flag to export **just** this function, but it doesn't appear to work no matter where I put the flag in relation to reference to the `.a` archives. Instead, the problem can be dealt with by putting the JNI function in a separate static library, so that I can link it without changing symbol visibility, while making all the `System.Security.Cryptography.Native.Android` symbols invisible.
25d242e to
9521f00
Compare
This was referenced Dec 6, 2024
|
@grendello I'm not sure what state this is in. I've been assuming since October that someone else from .NET Android was going to sign off... it's outside of my domain. But since it's in my area and I'm trying to get things tidied up... "do we want this, or should we close the PR?" |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In dotnet/android#9006 we are working on linking the
.NET for Androidruntime dynamically at the application build time.
Linking includes all the relevant BCL native libraries, and one of the goals is to
hide all the exported symbols used as
p/invokesby the managed BCLlibraries. This is because
p/invokecalls are handled internally and,with dynamic linking of the runtime, there is no longer any reason to
use
dlopenanddlsymto look them up, they are all resolvedinternally, at the link time.
Symbol hiding works fine thanks to the
--exclude-libsclangflag,which makes all the exported symbols in the indicated
.aarchives tonot be exported by the linker. However,
System.Security.Cryptography.Native.Androidis special in the sense that it contains one symbol which must not be hidden,
Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate.The above function is a Java
nativemethod implementation, and itrequires that not only its name follows the Java JNI naming rules, but
that it is also available for the JVM to look up using
dlsym.I tried using the
--export-dynamic-symbolclang flag toexport just this function, but it doesn't appear to work no matter
where I put the flag in relation to reference to the
.aarchives.Instead, the problem can be dealt with by putting the JNI function in a
separate static library, so that I can link it without changing symbol
visibility, while making all the
System.Security.Cryptography.Native.Androidsymbols invisible.