[NativeAOT] set environment variables before the app .so is loaded#10709
Merged
[NativeAOT] set environment variables before the app .so is loaded#10709
Conversation
fe2a7e7 to
822ab55
Compare
Member
jonathanpeppers
left a comment
There was a problem hiding this comment.
is there some existing native code that needs to be disabled for NativeAOT? that is packing and setting env vars at startup?
src/Xamarin.Android.Build.Tasks/Resources/NativeAotRuntimeProvider.java
Outdated
Show resolved
Hide resolved
fb62ae0 to
6a5fa5b
Compare
Fixes:
(_LintChecks target) -> obj\Release\android\src\net\dot\jni\nativeaot\NativeAotRuntimeProvider.java(16): warning XA0102: The indentation string here is different from on the previous line (" " vs \t) [SuspiciousIndentation]
1711c8e to
71edf69
Compare
Contributor
Author
|
One timing test failed, irrelevant to the PR. Merging. |
jonathanpeppers
pushed a commit
that referenced
this pull request
Feb 4, 2026
…10709) Fixes: #10705 When a `NativeAOT` application starts up, certain portions of the managed startup sequence are executed on the shared library load but before the `JNI_OnLoad` function is invoked by Android. Both `MonoVM` and `CoreCLR` hosts set environment variables which may affect the way the application behaves before they initialize the managed runtime. Those variables are set from within native code, using data generated at application build time. Until now, the `NativeAOT` host followed suit, but it appears that we need to set certain variables (e.g. those related to running the startup hooks) before the shared library is loaded. The only location where we can do it is the `NativeAndroidRuntimeProvider` Java class which is responsible for, eventually, loading the application shared library. This commit makes our build process emit application environment variables into a Java file that's compiled together with the `NativeAndroidRuntimeProvider` class, at the same time removing those variables from the native code so that we don't set the variables twice (a performance optimization, nothing more). Testing shows that startup hooks are properly called with only the `DOTNET_STARTUP_HOOKS` variable set, which wasn't previously the case.
jonathanpeppers
added a commit
that referenced
this pull request
Feb 4, 2026
…10709) Fixes: #10705 When a \NativeAOT\ application starts up, certain portions of the managed startup sequence are executed on the shared library load but before the \JNI_OnLoad\ function is invoked by Android. Both \MonoVM\ and \CoreCLR\ hosts set environment variables which may affect the way the application behaves before they initialize the managed runtime. Those variables are set from within native code, using data generated at application build time. Until now, the \NativeAOT\ host followed suit, but it appears that we need to set certain variables (e.g. those related to running the startup hooks) before the shared library is loaded. The only location where we can do it is the \NativeAndroidRuntimeProvider\ Java class which is responsible for, eventually, loading the application shared library. This commit makes our build process emit application environment variables into a Java file that's compiled together with the \NativeAndroidRuntimeProvider\ class, at the same time removing those variables from the native code so that we don't set the variables twice (a performance optimization, nothing more). Testing shows that startup hooks are properly called with only the \DOTNET_STARTUP_HOOKS\ variable set, which wasn't previously the case. Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
jonathanpeppers
added a commit
that referenced
this pull request
Feb 5, 2026
…pp .so is loaded (#10768) Backport of: #10709 Fixes: #10705 When a `NativeAOT` application starts up, certain portions of the managed startup sequence are executed on the shared library load but before the `JNI_OnLoad` function is invoked by Android. Both `MonoVM` and `CoreCLR` hosts set environment variables which may affect the way the application behaves before they initialize the managed runtime. Those variables are set from within native code, using data generated at application build time. Until now, the `NativeAOT` host followed suit, but it appears that we need to set certain variables (e.g. those related to running the startup hooks) before the shared library is loaded. The only location where we can do it is the `NativeAndroidRuntimeProvider` Java class which is responsible for, eventually, loading the application shared library. This commit makes our build process emit application environment variables into a Java file that's compiled together with the `NativeAndroidRuntimeProvider` class, at the same time removing those variables from the native code so that we don't set the variables twice (a performance optimization, nothing more). Testing shows that startup hooks are properly called with only the `DOTNET_STARTUP_HOOKS` variable set, which wasn't previously the case. Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com> Co-authored-by: Marek Habersack <grendel@twistedcode.net>
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
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.
Fixes: #10705
When a NativeAOT application starts up, certain portions of the managed startup
sequence are executed on the shared library load but before the
JNI_OnLoadfunction is invoked by Android.
Both
MonoVMandCoreCLRhosts set environment variables which may affect theway the application behaves before they initialize the managed runtime. Those
variables are set from within native code, using data generated at application
build time.
Until now, the
NativeAOThost followed suit, but it appears that we need toset certain variables (e.g. those related to running the startup hooks) before
the shared library is loaded.
The only location where we can do it is the
NativeAndroidRuntimeProviderJavaclass which is responsible for, eventually, loading the application shared
library.
This commit makes our build process emit application environment variables into
a Java file that's compiled together with the
NativeAndroidRuntimeProviderclass, at the same time removing those variables from the native code so that
we don't set the variables twice (a performance optimization, nothing more).
Testing shows that startup hooks are properly called with only the
DOTNET_STARTUP_HOOKSvariable set, which wasn't previously the case.