[Android] Put Java JNI function in a separate static library

[grendello]

In dotnet/android#9006 we are working on linking the .NET for Android
runtime 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/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-libsclang 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 it 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.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[bartonjs]

@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?"

[Copilot]

Pull Request Overview

This PR refactors the Android cryptography native library to support dynamic linking in .NET for Android runtime by separating a Java JNI function into its own static library. The key motivation is to enable symbol hiding for all BCL native library exports while keeping the JNI function visible to the Java Virtual Machine.

• Move JNI function to separate static library to control symbol visibility during dynamic linking
• Refactor callback storage mechanism to support the new architecture
• Update build configuration to include the new static library in all relevant targets

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pal_trust_manager_jni_export.c	New file containing the JNI function and atomic callback storage
pal_trust_manager.h	Add function declaration for the new callback storage function
pal_trust_manager.c	Remove JNI function and atomic storage, delegate to new storage function
CMakeLists.txt	Add new static library target for JNI exports with detailed comments
apphost/static/CMakeLists.txt	Include new static library in native libs list
Directory.Build.props	Add new static library to platform manifest

Comments suppressed due to low confidence (1)

src/native/libs/System.Security.Cryptography.Native.Android/pal_trust_manager_jni_export.c:6

• The function name 'StoreRemoteVerificationCallback' doesn't follow the established naming convention. Based on the existing code pattern, it should be prefixed with 'AndroidCryptoNative_' like other public functions in this module.

void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback)

[filipnavara]

I am not necessarily opposed to it but this feels like a pretty heavy solution. In case of NativeAOT it's possible to fix this with just including this in MSBuild item group:

<IlcArgInclude="--export-dynamic-symbol:Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate" />

The build process generates an exports file which is then fed to the linker. I wonder if the CoreCLR/Android build process uses something similar because the linker script takes a precedence over --export-dynamic-symbol argument to clang/lld.

For reference, the NativeAOT exports file looks like this:

V1.0 {
global:
Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate;
JNI_OnLoad;
JNI_OnUnload;
Java_net_dot_jni_nativeaot_JavaInteropRuntime_init;
local: *;
};

[grendello]

@filipnavara I played with the option you mention, with varying success. The goal I have in mind is to hide symbols by default with few exceptions, and for static linking this is easier than playing with --export-dynamic-symbol for X symbols.

[grendello]

When linking statically a NativeAOT app, does it really need to export the symbol though?

Yes, it does. It's a JNI interface and the JavaVM/Dalvik looks for it.

Yeah, you're right. I forgot it is actually called from Java.

[grendello]

Eventually, I think the runtime pack should provide a manifest of libraries that are to be used for linking as well as the init functions to call (if any) and what symbols to export.

For now, I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

[jkotas]

I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

I agree - the export should be next to logic that references the library. Add --export-dynamic-symbol:... next to the line that references the library in the NAOT buildintegration in this PR?

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_reviewed_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_recorded_worker_run_id": "29672719152",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"review_id": 4729976780
}
]
}

[github-actions]

Holistic Review

Motivation: For .NET for Android dynamic runtime linking (dotnet/android#9006), all BCL native libraries are linked into a single .so and their exported symbols are hidden via clang's --exclude-libs applied to the .a archives. System.Security.Cryptography.Native.Android contains one symbol that must stay exported: the JNI native method Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate, which the JVM resolves via dlsym. Attempts to selectively re-export it with --export-dynamic-symbol did not work because a linker version script takes precedence.

Approach: The JNI entry point plus its backing static _Atomic callback state and a new StoreRemoteVerificationCallback accessor are moved into a new translation unit pal_trust_manager_jni_export.c, compiled into a dedicated static archive System.Security.Cryptography.Native.Android.JNIExport-Static (output name ...JNIExport). This lets the Android build exclude the main crypto archive from symbol hiding while keeping the single JNI symbol exported through the separate archive. The shared library still compiles the JNI source directly, so its behavior is unchanged. Supporting plumbing is added: the new archive is registered in the static apphost NATIVE_LIBS, in the shared-framework platform manifest, and (for NativeAOT) in Microsoft.NETCore.Native.Unix.targets alongside an --export-dynamic-symbolIlcArg. The refactor also adds the standard MIT license headers to pal_trust_manager.{c,h}.

Summary: This is a focused, correct build/packaging refactor. The atomic callback variable and its sole consumer (the JNI function) remain in the same translation unit, so the store/load pairing and abort_unless guard semantics are preserved; the register function in pal_trust_manager.c now delegates to StoreRemoteVerificationCallback in that same unit. Both the shared and static link paths are updated consistently, and the NativeAOT path is covered separately. Only minor style nits (a space before the parenthesis in StoreRemoteVerificationCallback (...) in the header and implementation) deviate from the surrounding code; these are non-blocking. Verdict: LGTM. Note: functional validation depends on Android CI build/link of the split archives, which I did not run.

Detailed Findings

• Minor style: void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback) (in pal_trust_manager.h and pal_trust_manager_jni_export.c) has a space before the opening parenthesis, inconsistent with the rest of the file. Non-blocking.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 51 AIC · ⌖ 10.5 AIC · ⊞ 10K

[grendello]

In dotnet/android#9006 we are working on linking the .NET for Android
runtime 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/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-libsclang 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 it 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.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[bartonjs]

@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?"

[Copilot]

Pull Request Overview

This PR refactors the Android cryptography native library to support dynamic linking in .NET for Android runtime by separating a Java JNI function into its own static library. The key motivation is to enable symbol hiding for all BCL native library exports while keeping the JNI function visible to the Java Virtual Machine.

• Move JNI function to separate static library to control symbol visibility during dynamic linking
• Refactor callback storage mechanism to support the new architecture
• Update build configuration to include the new static library in all relevant targets

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pal_trust_manager_jni_export.c	New file containing the JNI function and atomic callback storage
pal_trust_manager.h	Add function declaration for the new callback storage function
pal_trust_manager.c	Remove JNI function and atomic storage, delegate to new storage function
CMakeLists.txt	Add new static library target for JNI exports with detailed comments
apphost/static/CMakeLists.txt	Include new static library in native libs list
Directory.Build.props	Add new static library to platform manifest

Comments suppressed due to low confidence (1)

src/native/libs/System.Security.Cryptography.Native.Android/pal_trust_manager_jni_export.c:6

• The function name 'StoreRemoteVerificationCallback' doesn't follow the established naming convention. Based on the existing code pattern, it should be prefixed with 'AndroidCryptoNative_' like other public functions in this module.

void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback)

[filipnavara]

I am not necessarily opposed to it but this feels like a pretty heavy solution. In case of NativeAOT it's possible to fix this with just including this in MSBuild item group:

<IlcArgInclude="--export-dynamic-symbol:Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate" />

The build process generates an exports file which is then fed to the linker. I wonder if the CoreCLR/Android build process uses something similar because the linker script takes a precedence over --export-dynamic-symbol argument to clang/lld.

For reference, the NativeAOT exports file looks like this:

V1.0 {
global:
Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate;
JNI_OnLoad;
JNI_OnUnload;
Java_net_dot_jni_nativeaot_JavaInteropRuntime_init;
local: *;
};

[grendello]

@filipnavara I played with the option you mention, with varying success. The goal I have in mind is to hide symbols by default with few exceptions, and for static linking this is easier than playing with --export-dynamic-symbol for X symbols.

[grendello]

When linking statically a NativeAOT app, does it really need to export the symbol though?

Yes, it does. It's a JNI interface and the JavaVM/Dalvik looks for it.

Yeah, you're right. I forgot it is actually called from Java.

[grendello]

Eventually, I think the runtime pack should provide a manifest of libraries that are to be used for linking as well as the init functions to call (if any) and what symbols to export.

For now, I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

[jkotas]

I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

I agree - the export should be next to logic that references the library. Add --export-dynamic-symbol:... next to the line that references the library in the NAOT buildintegration in this PR?

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_reviewed_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_recorded_worker_run_id": "29672719152",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"review_id": 4729976780
}
]
}

[github-actions]

Holistic Review

Motivation: For .NET for Android dynamic runtime linking (dotnet/android#9006), all BCL native libraries are linked into a single .so and their exported symbols are hidden via clang's --exclude-libs applied to the .a archives. System.Security.Cryptography.Native.Android contains one symbol that must stay exported: the JNI native method Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate, which the JVM resolves via dlsym. Attempts to selectively re-export it with --export-dynamic-symbol did not work because a linker version script takes precedence.

Approach: The JNI entry point plus its backing static _Atomic callback state and a new StoreRemoteVerificationCallback accessor are moved into a new translation unit pal_trust_manager_jni_export.c, compiled into a dedicated static archive System.Security.Cryptography.Native.Android.JNIExport-Static (output name ...JNIExport). This lets the Android build exclude the main crypto archive from symbol hiding while keeping the single JNI symbol exported through the separate archive. The shared library still compiles the JNI source directly, so its behavior is unchanged. Supporting plumbing is added: the new archive is registered in the static apphost NATIVE_LIBS, in the shared-framework platform manifest, and (for NativeAOT) in Microsoft.NETCore.Native.Unix.targets alongside an --export-dynamic-symbolIlcArg. The refactor also adds the standard MIT license headers to pal_trust_manager.{c,h}.

Summary: This is a focused, correct build/packaging refactor. The atomic callback variable and its sole consumer (the JNI function) remain in the same translation unit, so the store/load pairing and abort_unless guard semantics are preserved; the register function in pal_trust_manager.c now delegates to StoreRemoteVerificationCallback in that same unit. Both the shared and static link paths are updated consistently, and the NativeAOT path is covered separately. Only minor style nits (a space before the parenthesis in StoreRemoteVerificationCallback (...) in the header and implementation) deviate from the surrounding code; these are non-blocking. Verdict: LGTM. Note: functional validation depends on Android CI build/link of the split archives, which I did not run.

Detailed Findings

• Minor style: void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback) (in pal_trust_manager.h and pal_trust_manager_jni_export.c) has a space before the opening parenthesis, inconsistent with the rest of the file. Non-blocking.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 51 AIC · ⌖ 10.5 AIC · ⊞ 10K

[grendello]

In dotnet/android#9006 we are working on linking the .NET for Android
runtime 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/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-libsclang 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 it 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.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[bartonjs]

@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?"

[Copilot]

Pull Request Overview

This PR refactors the Android cryptography native library to support dynamic linking in .NET for Android runtime by separating a Java JNI function into its own static library. The key motivation is to enable symbol hiding for all BCL native library exports while keeping the JNI function visible to the Java Virtual Machine.

• Move JNI function to separate static library to control symbol visibility during dynamic linking
• Refactor callback storage mechanism to support the new architecture
• Update build configuration to include the new static library in all relevant targets

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pal_trust_manager_jni_export.c	New file containing the JNI function and atomic callback storage
pal_trust_manager.h	Add function declaration for the new callback storage function
pal_trust_manager.c	Remove JNI function and atomic storage, delegate to new storage function
CMakeLists.txt	Add new static library target for JNI exports with detailed comments
apphost/static/CMakeLists.txt	Include new static library in native libs list
Directory.Build.props	Add new static library to platform manifest

Comments suppressed due to low confidence (1)

src/native/libs/System.Security.Cryptography.Native.Android/pal_trust_manager_jni_export.c:6

• The function name 'StoreRemoteVerificationCallback' doesn't follow the established naming convention. Based on the existing code pattern, it should be prefixed with 'AndroidCryptoNative_' like other public functions in this module.

void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback)

[filipnavara]

I am not necessarily opposed to it but this feels like a pretty heavy solution. In case of NativeAOT it's possible to fix this with just including this in MSBuild item group:

<IlcArgInclude="--export-dynamic-symbol:Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate" />

The build process generates an exports file which is then fed to the linker. I wonder if the CoreCLR/Android build process uses something similar because the linker script takes a precedence over --export-dynamic-symbol argument to clang/lld.

For reference, the NativeAOT exports file looks like this:

V1.0 {
global:
Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate;
JNI_OnLoad;
JNI_OnUnload;
Java_net_dot_jni_nativeaot_JavaInteropRuntime_init;
local: *;
};

[grendello]

@filipnavara I played with the option you mention, with varying success. The goal I have in mind is to hide symbols by default with few exceptions, and for static linking this is easier than playing with --export-dynamic-symbol for X symbols.

[grendello]

When linking statically a NativeAOT app, does it really need to export the symbol though?

Yes, it does. It's a JNI interface and the JavaVM/Dalvik looks for it.

Yeah, you're right. I forgot it is actually called from Java.

[grendello]

Eventually, I think the runtime pack should provide a manifest of libraries that are to be used for linking as well as the init functions to call (if any) and what symbols to export.

For now, I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

[jkotas]

I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

I agree - the export should be next to logic that references the library. Add --export-dynamic-symbol:... next to the line that references the library in the NAOT buildintegration in this PR?

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_reviewed_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_recorded_worker_run_id": "29672719152",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"review_id": 4729976780
}
]
}

[github-actions]

Holistic Review

Motivation: For .NET for Android dynamic runtime linking (dotnet/android#9006), all BCL native libraries are linked into a single .so and their exported symbols are hidden via clang's --exclude-libs applied to the .a archives. System.Security.Cryptography.Native.Android contains one symbol that must stay exported: the JNI native method Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate, which the JVM resolves via dlsym. Attempts to selectively re-export it with --export-dynamic-symbol did not work because a linker version script takes precedence.

Approach: The JNI entry point plus its backing static _Atomic callback state and a new StoreRemoteVerificationCallback accessor are moved into a new translation unit pal_trust_manager_jni_export.c, compiled into a dedicated static archive System.Security.Cryptography.Native.Android.JNIExport-Static (output name ...JNIExport). This lets the Android build exclude the main crypto archive from symbol hiding while keeping the single JNI symbol exported through the separate archive. The shared library still compiles the JNI source directly, so its behavior is unchanged. Supporting plumbing is added: the new archive is registered in the static apphost NATIVE_LIBS, in the shared-framework platform manifest, and (for NativeAOT) in Microsoft.NETCore.Native.Unix.targets alongside an --export-dynamic-symbolIlcArg. The refactor also adds the standard MIT license headers to pal_trust_manager.{c,h}.

Summary: This is a focused, correct build/packaging refactor. The atomic callback variable and its sole consumer (the JNI function) remain in the same translation unit, so the store/load pairing and abort_unless guard semantics are preserved; the register function in pal_trust_manager.c now delegates to StoreRemoteVerificationCallback in that same unit. Both the shared and static link paths are updated consistently, and the NativeAOT path is covered separately. Only minor style nits (a space before the parenthesis in StoreRemoteVerificationCallback (...) in the header and implementation) deviate from the surrounding code; these are non-blocking. Verdict: LGTM. Note: functional validation depends on Android CI build/link of the split archives, which I did not run.

Detailed Findings

• Minor style: void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback) (in pal_trust_manager.h and pal_trust_manager_jni_export.c) has a space before the opening parenthesis, inconsistent with the rest of the file. Non-blocking.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 51 AIC · ⌖ 10.5 AIC · ⊞ 10K

[grendello]

In dotnet/android#9006 we are working on linking the .NET for Android
runtime 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/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-libsclang 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 it 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.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[bartonjs]

@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?"

[Copilot]

Pull Request Overview

This PR refactors the Android cryptography native library to support dynamic linking in .NET for Android runtime by separating a Java JNI function into its own static library. The key motivation is to enable symbol hiding for all BCL native library exports while keeping the JNI function visible to the Java Virtual Machine.

• Move JNI function to separate static library to control symbol visibility during dynamic linking
• Refactor callback storage mechanism to support the new architecture
• Update build configuration to include the new static library in all relevant targets

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pal_trust_manager_jni_export.c	New file containing the JNI function and atomic callback storage
pal_trust_manager.h	Add function declaration for the new callback storage function
pal_trust_manager.c	Remove JNI function and atomic storage, delegate to new storage function
CMakeLists.txt	Add new static library target for JNI exports with detailed comments
apphost/static/CMakeLists.txt	Include new static library in native libs list
Directory.Build.props	Add new static library to platform manifest

Comments suppressed due to low confidence (1)

src/native/libs/System.Security.Cryptography.Native.Android/pal_trust_manager_jni_export.c:6

• The function name 'StoreRemoteVerificationCallback' doesn't follow the established naming convention. Based on the existing code pattern, it should be prefixed with 'AndroidCryptoNative_' like other public functions in this module.

void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback)

[filipnavara]

I am not necessarily opposed to it but this feels like a pretty heavy solution. In case of NativeAOT it's possible to fix this with just including this in MSBuild item group:

<IlcArgInclude="--export-dynamic-symbol:Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate" />

The build process generates an exports file which is then fed to the linker. I wonder if the CoreCLR/Android build process uses something similar because the linker script takes a precedence over --export-dynamic-symbol argument to clang/lld.

For reference, the NativeAOT exports file looks like this:

V1.0 {
global:
Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate;
JNI_OnLoad;
JNI_OnUnload;
Java_net_dot_jni_nativeaot_JavaInteropRuntime_init;
local: *;
};

[grendello]

@filipnavara I played with the option you mention, with varying success. The goal I have in mind is to hide symbols by default with few exceptions, and for static linking this is easier than playing with --export-dynamic-symbol for X symbols.

[grendello]

When linking statically a NativeAOT app, does it really need to export the symbol though?

Yes, it does. It's a JNI interface and the JavaVM/Dalvik looks for it.

Yeah, you're right. I forgot it is actually called from Java.

[grendello]

Eventually, I think the runtime pack should provide a manifest of libraries that are to be used for linking as well as the init functions to call (if any) and what symbols to export.

For now, I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

[jkotas]

I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

I agree - the export should be next to logic that references the library. Add --export-dynamic-symbol:... next to the line that references the library in the NAOT buildintegration in this PR?

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_reviewed_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_recorded_worker_run_id": "29672719152",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"review_id": 4729976780
}
]
}

[github-actions]

Holistic Review

Motivation: For .NET for Android dynamic runtime linking (dotnet/android#9006), all BCL native libraries are linked into a single .so and their exported symbols are hidden via clang's --exclude-libs applied to the .a archives. System.Security.Cryptography.Native.Android contains one symbol that must stay exported: the JNI native method Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate, which the JVM resolves via dlsym. Attempts to selectively re-export it with --export-dynamic-symbol did not work because a linker version script takes precedence.

Approach: The JNI entry point plus its backing static _Atomic callback state and a new StoreRemoteVerificationCallback accessor are moved into a new translation unit pal_trust_manager_jni_export.c, compiled into a dedicated static archive System.Security.Cryptography.Native.Android.JNIExport-Static (output name ...JNIExport). This lets the Android build exclude the main crypto archive from symbol hiding while keeping the single JNI symbol exported through the separate archive. The shared library still compiles the JNI source directly, so its behavior is unchanged. Supporting plumbing is added: the new archive is registered in the static apphost NATIVE_LIBS, in the shared-framework platform manifest, and (for NativeAOT) in Microsoft.NETCore.Native.Unix.targets alongside an --export-dynamic-symbolIlcArg. The refactor also adds the standard MIT license headers to pal_trust_manager.{c,h}.

Summary: This is a focused, correct build/packaging refactor. The atomic callback variable and its sole consumer (the JNI function) remain in the same translation unit, so the store/load pairing and abort_unless guard semantics are preserved; the register function in pal_trust_manager.c now delegates to StoreRemoteVerificationCallback in that same unit. Both the shared and static link paths are updated consistently, and the NativeAOT path is covered separately. Only minor style nits (a space before the parenthesis in StoreRemoteVerificationCallback (...) in the header and implementation) deviate from the surrounding code; these are non-blocking. Verdict: LGTM. Note: functional validation depends on Android CI build/link of the split archives, which I did not run.

Detailed Findings

• Minor style: void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback) (in pal_trust_manager.h and pal_trust_manager_jni_export.c) has a space before the opening parenthesis, inconsistent with the rest of the file. Non-blocking.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 51 AIC · ⌖ 10.5 AIC · ⊞ 10K

[grendello]

In dotnet/android#9006 we are working on linking the .NET for Android
runtime 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/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-libsclang 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 it 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.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[bartonjs]

@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?"

[Copilot]

Pull Request Overview

This PR refactors the Android cryptography native library to support dynamic linking in .NET for Android runtime by separating a Java JNI function into its own static library. The key motivation is to enable symbol hiding for all BCL native library exports while keeping the JNI function visible to the Java Virtual Machine.

• Move JNI function to separate static library to control symbol visibility during dynamic linking
• Refactor callback storage mechanism to support the new architecture
• Update build configuration to include the new static library in all relevant targets

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pal_trust_manager_jni_export.c	New file containing the JNI function and atomic callback storage
pal_trust_manager.h	Add function declaration for the new callback storage function
pal_trust_manager.c	Remove JNI function and atomic storage, delegate to new storage function
CMakeLists.txt	Add new static library target for JNI exports with detailed comments
apphost/static/CMakeLists.txt	Include new static library in native libs list
Directory.Build.props	Add new static library to platform manifest

Comments suppressed due to low confidence (1)

src/native/libs/System.Security.Cryptography.Native.Android/pal_trust_manager_jni_export.c:6

• The function name 'StoreRemoteVerificationCallback' doesn't follow the established naming convention. Based on the existing code pattern, it should be prefixed with 'AndroidCryptoNative_' like other public functions in this module.

void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback)

[filipnavara]

I am not necessarily opposed to it but this feels like a pretty heavy solution. In case of NativeAOT it's possible to fix this with just including this in MSBuild item group:

<IlcArgInclude="--export-dynamic-symbol:Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate" />

The build process generates an exports file which is then fed to the linker. I wonder if the CoreCLR/Android build process uses something similar because the linker script takes a precedence over --export-dynamic-symbol argument to clang/lld.

For reference, the NativeAOT exports file looks like this:

V1.0 {
global:
Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate;
JNI_OnLoad;
JNI_OnUnload;
Java_net_dot_jni_nativeaot_JavaInteropRuntime_init;
local: *;
};

[grendello]

@filipnavara I played with the option you mention, with varying success. The goal I have in mind is to hide symbols by default with few exceptions, and for static linking this is easier than playing with --export-dynamic-symbol for X symbols.

[grendello]

When linking statically a NativeAOT app, does it really need to export the symbol though?

Yes, it does. It's a JNI interface and the JavaVM/Dalvik looks for it.

Yeah, you're right. I forgot it is actually called from Java.

[grendello]

Eventually, I think the runtime pack should provide a manifest of libraries that are to be used for linking as well as the init functions to call (if any) and what symbols to export.

For now, I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

[jkotas]

I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

I agree - the export should be next to logic that references the library. Add --export-dynamic-symbol:... next to the line that references the library in the NAOT buildintegration in this PR?

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_reviewed_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_recorded_worker_run_id": "29672719152",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"review_id": 4729976780
}
]
}

[github-actions]

Holistic Review

Motivation: For .NET for Android dynamic runtime linking (dotnet/android#9006), all BCL native libraries are linked into a single .so and their exported symbols are hidden via clang's --exclude-libs applied to the .a archives. System.Security.Cryptography.Native.Android contains one symbol that must stay exported: the JNI native method Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate, which the JVM resolves via dlsym. Attempts to selectively re-export it with --export-dynamic-symbol did not work because a linker version script takes precedence.

Approach: The JNI entry point plus its backing static _Atomic callback state and a new StoreRemoteVerificationCallback accessor are moved into a new translation unit pal_trust_manager_jni_export.c, compiled into a dedicated static archive System.Security.Cryptography.Native.Android.JNIExport-Static (output name ...JNIExport). This lets the Android build exclude the main crypto archive from symbol hiding while keeping the single JNI symbol exported through the separate archive. The shared library still compiles the JNI source directly, so its behavior is unchanged. Supporting plumbing is added: the new archive is registered in the static apphost NATIVE_LIBS, in the shared-framework platform manifest, and (for NativeAOT) in Microsoft.NETCore.Native.Unix.targets alongside an --export-dynamic-symbolIlcArg. The refactor also adds the standard MIT license headers to pal_trust_manager.{c,h}.

Summary: This is a focused, correct build/packaging refactor. The atomic callback variable and its sole consumer (the JNI function) remain in the same translation unit, so the store/load pairing and abort_unless guard semantics are preserved; the register function in pal_trust_manager.c now delegates to StoreRemoteVerificationCallback in that same unit. Both the shared and static link paths are updated consistently, and the NativeAOT path is covered separately. Only minor style nits (a space before the parenthesis in StoreRemoteVerificationCallback (...) in the header and implementation) deviate from the surrounding code; these are non-blocking. Verdict: LGTM. Note: functional validation depends on Android CI build/link of the split archives, which I did not run.

Detailed Findings

• Minor style: void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback) (in pal_trust_manager.h and pal_trust_manager_jni_export.c) has a space before the opening parenthesis, inconsistent with the rest of the file. Non-blocking.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 51 AIC · ⌖ 10.5 AIC · ⊞ 10K

[grendello]

In dotnet/android#9006 we are working on linking the .NET for Android
runtime 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/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-libsclang 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 it 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.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[bartonjs]

@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?"

[Copilot]

Pull Request Overview

This PR refactors the Android cryptography native library to support dynamic linking in .NET for Android runtime by separating a Java JNI function into its own static library. The key motivation is to enable symbol hiding for all BCL native library exports while keeping the JNI function visible to the Java Virtual Machine.

• Move JNI function to separate static library to control symbol visibility during dynamic linking
• Refactor callback storage mechanism to support the new architecture
• Update build configuration to include the new static library in all relevant targets

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pal_trust_manager_jni_export.c	New file containing the JNI function and atomic callback storage
pal_trust_manager.h	Add function declaration for the new callback storage function
pal_trust_manager.c	Remove JNI function and atomic storage, delegate to new storage function
CMakeLists.txt	Add new static library target for JNI exports with detailed comments
apphost/static/CMakeLists.txt	Include new static library in native libs list
Directory.Build.props	Add new static library to platform manifest

Comments suppressed due to low confidence (1)

src/native/libs/System.Security.Cryptography.Native.Android/pal_trust_manager_jni_export.c:6

• The function name 'StoreRemoteVerificationCallback' doesn't follow the established naming convention. Based on the existing code pattern, it should be prefixed with 'AndroidCryptoNative_' like other public functions in this module.

void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback)

[filipnavara]

I am not necessarily opposed to it but this feels like a pretty heavy solution. In case of NativeAOT it's possible to fix this with just including this in MSBuild item group:

<IlcArgInclude="--export-dynamic-symbol:Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate" />

The build process generates an exports file which is then fed to the linker. I wonder if the CoreCLR/Android build process uses something similar because the linker script takes a precedence over --export-dynamic-symbol argument to clang/lld.

For reference, the NativeAOT exports file looks like this:

V1.0 {
global:
Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate;
JNI_OnLoad;
JNI_OnUnload;
Java_net_dot_jni_nativeaot_JavaInteropRuntime_init;
local: *;
};

[grendello]

@filipnavara I played with the option you mention, with varying success. The goal I have in mind is to hide symbols by default with few exceptions, and for static linking this is easier than playing with --export-dynamic-symbol for X symbols.

[grendello]

When linking statically a NativeAOT app, does it really need to export the symbol though?

Yes, it does. It's a JNI interface and the JavaVM/Dalvik looks for it.

Yeah, you're right. I forgot it is actually called from Java.

[grendello]

Eventually, I think the runtime pack should provide a manifest of libraries that are to be used for linking as well as the init functions to call (if any) and what symbols to export.

For now, I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

[jkotas]

I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

I agree - the export should be next to logic that references the library. Add --export-dynamic-symbol:... next to the line that references the library in the NAOT buildintegration in this PR?

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_reviewed_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_recorded_worker_run_id": "29672719152",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"review_id": 4729976780
}
]
}

[github-actions]

Holistic Review

Motivation: For .NET for Android dynamic runtime linking (dotnet/android#9006), all BCL native libraries are linked into a single .so and their exported symbols are hidden via clang's --exclude-libs applied to the .a archives. System.Security.Cryptography.Native.Android contains one symbol that must stay exported: the JNI native method Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate, which the JVM resolves via dlsym. Attempts to selectively re-export it with --export-dynamic-symbol did not work because a linker version script takes precedence.

Approach: The JNI entry point plus its backing static _Atomic callback state and a new StoreRemoteVerificationCallback accessor are moved into a new translation unit pal_trust_manager_jni_export.c, compiled into a dedicated static archive System.Security.Cryptography.Native.Android.JNIExport-Static (output name ...JNIExport). This lets the Android build exclude the main crypto archive from symbol hiding while keeping the single JNI symbol exported through the separate archive. The shared library still compiles the JNI source directly, so its behavior is unchanged. Supporting plumbing is added: the new archive is registered in the static apphost NATIVE_LIBS, in the shared-framework platform manifest, and (for NativeAOT) in Microsoft.NETCore.Native.Unix.targets alongside an --export-dynamic-symbolIlcArg. The refactor also adds the standard MIT license headers to pal_trust_manager.{c,h}.

Summary: This is a focused, correct build/packaging refactor. The atomic callback variable and its sole consumer (the JNI function) remain in the same translation unit, so the store/load pairing and abort_unless guard semantics are preserved; the register function in pal_trust_manager.c now delegates to StoreRemoteVerificationCallback in that same unit. Both the shared and static link paths are updated consistently, and the NativeAOT path is covered separately. Only minor style nits (a space before the parenthesis in StoreRemoteVerificationCallback (...) in the header and implementation) deviate from the surrounding code; these are non-blocking. Verdict: LGTM. Note: functional validation depends on Android CI build/link of the split archives, which I did not run.

Detailed Findings

• Minor style: void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback) (in pal_trust_manager.h and pal_trust_manager_jni_export.c) has a space before the opening parenthesis, inconsistent with the rest of the file. Non-blocking.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 51 AIC · ⌖ 10.5 AIC · ⊞ 10K

[grendello]

In dotnet/android#9006 we are working on linking the .NET for Android
runtime 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/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-libsclang 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 it 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.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[bartonjs]

@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?"

[Copilot]

Pull Request Overview

This PR refactors the Android cryptography native library to support dynamic linking in .NET for Android runtime by separating a Java JNI function into its own static library. The key motivation is to enable symbol hiding for all BCL native library exports while keeping the JNI function visible to the Java Virtual Machine.

• Move JNI function to separate static library to control symbol visibility during dynamic linking
• Refactor callback storage mechanism to support the new architecture
• Update build configuration to include the new static library in all relevant targets

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pal_trust_manager_jni_export.c	New file containing the JNI function and atomic callback storage
pal_trust_manager.h	Add function declaration for the new callback storage function
pal_trust_manager.c	Remove JNI function and atomic storage, delegate to new storage function
CMakeLists.txt	Add new static library target for JNI exports with detailed comments
apphost/static/CMakeLists.txt	Include new static library in native libs list
Directory.Build.props	Add new static library to platform manifest

Comments suppressed due to low confidence (1)

src/native/libs/System.Security.Cryptography.Native.Android/pal_trust_manager_jni_export.c:6

• The function name 'StoreRemoteVerificationCallback' doesn't follow the established naming convention. Based on the existing code pattern, it should be prefixed with 'AndroidCryptoNative_' like other public functions in this module.

void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback)

[filipnavara]

I am not necessarily opposed to it but this feels like a pretty heavy solution. In case of NativeAOT it's possible to fix this with just including this in MSBuild item group:

<IlcArgInclude="--export-dynamic-symbol:Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate" />

The build process generates an exports file which is then fed to the linker. I wonder if the CoreCLR/Android build process uses something similar because the linker script takes a precedence over --export-dynamic-symbol argument to clang/lld.

For reference, the NativeAOT exports file looks like this:

V1.0 {
global:
Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate;
JNI_OnLoad;
JNI_OnUnload;
Java_net_dot_jni_nativeaot_JavaInteropRuntime_init;
local: *;
};

[grendello]

@filipnavara I played with the option you mention, with varying success. The goal I have in mind is to hide symbols by default with few exceptions, and for static linking this is easier than playing with --export-dynamic-symbol for X symbols.

[grendello]

When linking statically a NativeAOT app, does it really need to export the symbol though?

Yes, it does. It's a JNI interface and the JavaVM/Dalvik looks for it.

Yeah, you're right. I forgot it is actually called from Java.

[grendello]

Eventually, I think the runtime pack should provide a manifest of libraries that are to be used for linking as well as the init functions to call (if any) and what symbols to export.

For now, I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

[jkotas]

I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

I agree - the export should be next to logic that references the library. Add --export-dynamic-symbol:... next to the line that references the library in the NAOT buildintegration in this PR?

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_reviewed_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_recorded_worker_run_id": "29672719152",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"review_id": 4729976780
}
]
}

[github-actions]

Holistic Review

Motivation: For .NET for Android dynamic runtime linking (dotnet/android#9006), all BCL native libraries are linked into a single .so and their exported symbols are hidden via clang's --exclude-libs applied to the .a archives. System.Security.Cryptography.Native.Android contains one symbol that must stay exported: the JNI native method Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate, which the JVM resolves via dlsym. Attempts to selectively re-export it with --export-dynamic-symbol did not work because a linker version script takes precedence.

Approach: The JNI entry point plus its backing static _Atomic callback state and a new StoreRemoteVerificationCallback accessor are moved into a new translation unit pal_trust_manager_jni_export.c, compiled into a dedicated static archive System.Security.Cryptography.Native.Android.JNIExport-Static (output name ...JNIExport). This lets the Android build exclude the main crypto archive from symbol hiding while keeping the single JNI symbol exported through the separate archive. The shared library still compiles the JNI source directly, so its behavior is unchanged. Supporting plumbing is added: the new archive is registered in the static apphost NATIVE_LIBS, in the shared-framework platform manifest, and (for NativeAOT) in Microsoft.NETCore.Native.Unix.targets alongside an --export-dynamic-symbolIlcArg. The refactor also adds the standard MIT license headers to pal_trust_manager.{c,h}.

Summary: This is a focused, correct build/packaging refactor. The atomic callback variable and its sole consumer (the JNI function) remain in the same translation unit, so the store/load pairing and abort_unless guard semantics are preserved; the register function in pal_trust_manager.c now delegates to StoreRemoteVerificationCallback in that same unit. Both the shared and static link paths are updated consistently, and the NativeAOT path is covered separately. Only minor style nits (a space before the parenthesis in StoreRemoteVerificationCallback (...) in the header and implementation) deviate from the surrounding code; these are non-blocking. Verdict: LGTM. Note: functional validation depends on Android CI build/link of the split archives, which I did not run.

Detailed Findings

• Minor style: void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback) (in pal_trust_manager.h and pal_trust_manager_jni_export.c) has a space before the opening parenthesis, inconsistent with the rest of the file. Non-blocking.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 51 AIC · ⌖ 10.5 AIC · ⊞ 10K

[grendello]

In dotnet/android#9006 we are working on linking the .NET for Android
runtime 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/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-libsclang 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 it 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.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[bartonjs]

@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?"

[Copilot]

Pull Request Overview

This PR refactors the Android cryptography native library to support dynamic linking in .NET for Android runtime by separating a Java JNI function into its own static library. The key motivation is to enable symbol hiding for all BCL native library exports while keeping the JNI function visible to the Java Virtual Machine.

• Move JNI function to separate static library to control symbol visibility during dynamic linking
• Refactor callback storage mechanism to support the new architecture
• Update build configuration to include the new static library in all relevant targets

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pal_trust_manager_jni_export.c	New file containing the JNI function and atomic callback storage
pal_trust_manager.h	Add function declaration for the new callback storage function
pal_trust_manager.c	Remove JNI function and atomic storage, delegate to new storage function
CMakeLists.txt	Add new static library target for JNI exports with detailed comments
apphost/static/CMakeLists.txt	Include new static library in native libs list
Directory.Build.props	Add new static library to platform manifest

Comments suppressed due to low confidence (1)

src/native/libs/System.Security.Cryptography.Native.Android/pal_trust_manager_jni_export.c:6

• The function name 'StoreRemoteVerificationCallback' doesn't follow the established naming convention. Based on the existing code pattern, it should be prefixed with 'AndroidCryptoNative_' like other public functions in this module.

void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback)

[filipnavara]

I am not necessarily opposed to it but this feels like a pretty heavy solution. In case of NativeAOT it's possible to fix this with just including this in MSBuild item group:

<IlcArgInclude="--export-dynamic-symbol:Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate" />

The build process generates an exports file which is then fed to the linker. I wonder if the CoreCLR/Android build process uses something similar because the linker script takes a precedence over --export-dynamic-symbol argument to clang/lld.

For reference, the NativeAOT exports file looks like this:

V1.0 {
global:
Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate;
JNI_OnLoad;
JNI_OnUnload;
Java_net_dot_jni_nativeaot_JavaInteropRuntime_init;
local: *;
};

[grendello]

@filipnavara I played with the option you mention, with varying success. The goal I have in mind is to hide symbols by default with few exceptions, and for static linking this is easier than playing with --export-dynamic-symbol for X symbols.

[grendello]

When linking statically a NativeAOT app, does it really need to export the symbol though?

Yes, it does. It's a JNI interface and the JavaVM/Dalvik looks for it.

Yeah, you're right. I forgot it is actually called from Java.

[grendello]

Eventually, I think the runtime pack should provide a manifest of libraries that are to be used for linking as well as the init functions to call (if any) and what symbols to export.

For now, I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

[jkotas]

I'd say responsibility to export this (and potentially others) symbol rests on the consumer (NativeAOT or Android in this case)

I agree - the export should be next to logic that references the library. Add --export-dynamic-symbol:... next to the line that references the library in the NAOT buildintegration in this PR?

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_reviewed_commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "bd94b146570c5f3057f29e40de901ca5154b7a92",
"last_recorded_worker_run_id": "29672719152",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "f573e20268e1d94196a6cf4eb2bc623de843e2f7",
"review_id": 4729976780
}
]
}

[github-actions]

Holistic Review

Motivation: For .NET for Android dynamic runtime linking (dotnet/android#9006), all BCL native libraries are linked into a single .so and their exported symbols are hidden via clang's --exclude-libs applied to the .a archives. System.Security.Cryptography.Native.Android contains one symbol that must stay exported: the JNI native method Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate, which the JVM resolves via dlsym. Attempts to selectively re-export it with --export-dynamic-symbol did not work because a linker version script takes precedence.

Approach: The JNI entry point plus its backing static _Atomic callback state and a new StoreRemoteVerificationCallback accessor are moved into a new translation unit pal_trust_manager_jni_export.c, compiled into a dedicated static archive System.Security.Cryptography.Native.Android.JNIExport-Static (output name ...JNIExport). This lets the Android build exclude the main crypto archive from symbol hiding while keeping the single JNI symbol exported through the separate archive. The shared library still compiles the JNI source directly, so its behavior is unchanged. Supporting plumbing is added: the new archive is registered in the static apphost NATIVE_LIBS, in the shared-framework platform manifest, and (for NativeAOT) in Microsoft.NETCore.Native.Unix.targets alongside an --export-dynamic-symbolIlcArg. The refactor also adds the standard MIT license headers to pal_trust_manager.{c,h}.

Summary: This is a focused, correct build/packaging refactor. The atomic callback variable and its sole consumer (the JNI function) remain in the same translation unit, so the store/load pairing and abort_unless guard semantics are preserved; the register function in pal_trust_manager.c now delegates to StoreRemoteVerificationCallback in that same unit. Both the shared and static link paths are updated consistently, and the NativeAOT path is covered separately. Only minor style nits (a space before the parenthesis in StoreRemoteVerificationCallback (...) in the header and implementation) deviate from the surrounding code; these are non-blocking. Verdict: LGTM. Note: functional validation depends on Android CI build/link of the split archives, which I did not run.

Detailed Findings

• Minor style: void StoreRemoteVerificationCallback (RemoteCertificateValidationCallback callback) (in pal_trust_manager.h and pal_trust_manager_jni_export.c) has a space before the opening parenthesis, inconsistent with the rest of the file. Non-blocking.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 51 AIC · ⌖ 10.5 AIC · ⊞ 10K