[CoreCLR] A library in AndroidNativeLibraryNoJniPreload is loaded with System.loadLibrary from the main thread on its first p/invoke, which fails 4 times in the system namespace before the call binds #13263

Activity

1. pawegio

   added

   Area: App RuntimeIssues in `libmonodroid.so`.Issues in `libmonodroid.so`.

   needs-triageIssues that need to be assigned.Issues that need to be assigned.

   on Oct 26, 2026
2. jonathanpeppers commented on Oct 27, 2026

   

   jonathanpeppers

   on Oct 27, 2026

   Member

   More actions

   🤖 AI-generated investigation: This comment was written by GitHub Copilot from a source-code and Git-history investigation. The reported failure matches the code paths described below. I have not reproduced the timings on a device, and the suggested workaround is not yet device-verified.

   Findings

   The main fault is in the shared JNI library loader, not in the meaning of AndroidNativeLibraryNoJniPreload.

   Android's System.loadLibrary selects a class loader from the calling Java class. Calling it from the main thread does not, by itself, provide an app Java caller. Our native looper callback calls java.lang.System.loadLibrary directly through JNI. The framework caller and system namespace shown in this report are consistent with that code path.

   Relevant source, at the revision inspected:

   • CoreClrBootstrapBuilder.cs: the exclusion removes the library from startup preloading but retains its JNI classification. That classification is necessary; excluding a library from early loading does not make it a non-JNI library.
   • DsoLoader: a later load of a JNI library still calls System.loadLibrary, with a main-thread dispatch when needed.
   • SystemLoadLibraryWrapper: calls the framework method directly and prints and clears the Java exception on failure.

   The other symptoms follow from this:

   Observation	Explanation
   Four failed loads	The P/Invoke handler tries a normalized name and the original name. Each attempt can make two more attempts in MonodroidDl, using the stored name and requested name. With one app library directory, this gives four attempts. The exact count can differ with packaging and runtime.
   Loading the library from the activity does not prevent the failures	The RTLD_NOLOAD handle lookup is after the Java load. A Java exception returns early, before the loader checks for an existing native handle.
   The P/Invoke eventually succeeds	The Android P/Invoke handler returns null. CoreCLR then uses its normal native-library resolution. This order is visible in dotnet/runtime's dllimport.cpp.
   Each new imported function can repeat the failures	CoreCLR calls the Android handler before its normal library-cache lookup. The unsuccessful Android path has not recorded a library handle, even if CoreCLR's fallback previously found the library.

   History and affected runtimes

   This is not a new .NET 11-only path, and the loader defect is not specific to CoreCLR.

   1. Use Android shared library loader for JNI libraries #10376, merged August 19, 2025, introduced Java loading for libraries exporting JNI_OnLoad, in place of loading them only with dlopen. It added the shared loader and main-thread callback used by both Mono and CoreCLR.
   2. The description of that change already documents the same limitation: loading through the main-thread callback can still select the system namespace and fail to find an app library. Startup preloading was added to avoid this failure in the usual case.
   3. Support for exempting native libraries from JNI preload #10787 added the preload exclusions. [release/10.0.1xx] Support for exempting native libraries from JNI preload #10879 backported them to .NET 10 on March 5, 2026.
   4. I checked release/10.0.1xx at commit 49516ae50dffb0421b7faf5f60f9df9cc220743d. Its Mono loader and CoreCLR loader both use the same shared JNI-loading path.

   Thus, source inspection indicates a pre-existing shared-loader defect exposed by skipping startup preloading. It does not establish that Mono has the same retry count, fallback outcome, or timing; those need a device comparison.

   Suggested workaround to try

   Keep AndroidNativeLibraryNoJniPreload for a library whose initialization must wait for the activity. Removing it could restore the original initialization-order problem.

   First try making one safe P/Invoke synchronously from MainActivity.OnCreate, after the activity state required by the library is ready, and before starting the worker thread. This keeps an app Java caller on the stack and avoids the native looper callback. If it succeeds through our loader, the stored library handle should allow later imports using the same library name to work from background threads without repeating the Java load.

   For the supplied repro, move the initial repro_add(2, 3) call into OnCreate. For Firebase, choose a native call that is valid at that initialization point; do not make an arbitrary call solely to force loading.

   Optional explicit Java callback

   AndroidJavaSource is the correct build-action spelling. An explicit Java wrapper can keep the first P/Invoke inside an app Java call:

   NativeLibraryWorkaround.java:

   package com.example.workaround;
   
   public final class NativeLibraryWorkaround {
       public static void initialize(String libraryName, Runnable firstCall) {
           System.loadLibrary(libraryName);
           firstCall.run();
       }
   }

   Java files inside the project are included and bound automatically. To set the metadata explicitly, use Update rather than adding a duplicate Include:

   <ItemGroup>
     <AndroidJavaSource Update="NativeLibraryWorkaround.java" Bind="true" />
     <AndroidNativeLibraryNoJniPreload Include="libreprolib.so" />
   </ItemGroup>

   Call the generated binding synchronously from OnCreate on the main thread:

   using var firstCall = new Java.Lang.Runnable (() => {
       var sum = repro_add (2, 3);
       Log.Info ("Repro", $"First P/Invoke returned {sum}");
   });
   
   Com.Example.Workaround.NativeLibraryWorkaround.Initialize (
       "reprolib", firstCall);

   Replace the library name and first call as appropriate. Do not start a thread or use await inside the callback: the first P/Invoke must occur while the Java callback is active on the main thread. A helper that only calls System.loadLibrary and returns before a later background P/Invoke is not enough, as the report already shows.

   To check the workaround, confirm that the first call has no failed Java loads or Shared library ... not loaded warning, then call additional imports from a worker thread and confirm that the failures do not return.

   Product fix direction

   Use an app-loaded Java helper as the caller of System.loadLibrary, instead of calling the framework method directly through JNI. This supplies the correct class loader without private Runtime.loadLibrary0 APIs. Main-thread dispatch is not required merely to select the class loader. Handle lookup and caching must also cover app-loaded libraries while preserving required JNI_OnLoad initialization.

   👍React with 👍1Reacted by Paweł Gajda
3. jonathanpeppers commented on Oct 27, 2026

   

   jonathanpeppers

   on Oct 27, 2026

   Member

   More actions

   @pawegio does the suggested workaround help?

   We can investigate the "Product fix direction", if that solves your issue.
4. pawegio commented on Oct 27, 2026

   

   pawegio

   on Oct 27, 2026

   Author

   More actions

   Thanks! Yes, it helps. With the first P/Invoke made synchronously in OnCreate, there are no failed loads.