[Copilot]

[Export] callback delegates created by CreateDynamicCallback() are only referenced by a local JniNativeMethodRegistration[] array passed to RegisterNatives(). Once the array goes out of scope, CoreCLR's GC collects the delegates, causing SIGABRT on first invocation. MonoVM was unaffected because it uses native trampolines rather than managed delegates.

Non-[Export] delegates are safe because generated connector code caches them in static fields (e.g. cb_onCreate). [Export] delegates have no such caching — they're created dynamically via Mono.Android.Export.dll and returned into a local.

Fix

• Add a static List<Delegate> in AndroidTypeManager to hold strong references to dynamically-created [Export] delegates
• Root each delegate immediately after CreateDynamicCallback() returns

+ static List<Delegate> prevent_delegate_gc = new List<Delegate> ();

  callback = CreateDynamicCallback (minfo);
+ prevent_delegate_gc.Add (callback);

Growth is bounded by the number of unique [Export] methods in the app (registered once per type).

Test

• Added ExportedMembersSurviveGarbageCollection device test in MonoAndroidExportTest.cs that verifies [Export] delegates survive GC on all runtimes by:
  1. Creating an object with [Export] methods (triggers delegate registration via RegisterNativeMembers)
  2. Forcing 10 aggressive GC cycles (GC.Collect + GC.WaitForPendingFinalizers)
  3. Invoking the [Export] method through JNI (GetObjectClass → GetMethodID → CallVoidMethod) to exercise the Java → native delegate → C# path
  4. Verifying the callback succeeds by checking logcat for the success message

Without the fix, the JNI call at step 3 crashes with SIGABRT on CoreCLR because the delegate backing n_Exported was collected.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[simonrozsival]

@copilot add a new test scenario which will allow us to verify that this fix solves the problem

[Copilot]

@copilot add a new test scenario which will allow us to verify that this fix solves the problem

Added ExportedMembersSurviveGarbageCollection test in 414b356. The test:

1. Creates a class with [Export] methods (triggers delegate registration via RegisterNativeMembers)
2. Forces 10 aggressive GC cycles (GC.Collect + GC.WaitForPendingFinalizers) to collect any unrooted delegates
3. Invokes the [Export] method through JNI (GetObjectClass → GetMethodID → CallVoidMethod) which exercises the Java → native delegate → C# path
4. Verifies the callback succeeds by checking logcat for the success message

Without the fix, the JNI call at step 3 would crash with SIGABRT on CoreCLR because the delegate backing n_Exported was collected. With the fix, the delegate is rooted in prevent_delegate_gc and the call succeeds.

[Copilot]

Pull request overview

This PR addresses a CoreCLR-specific crash where dynamically-created [Export] JNI callback delegates can be garbage-collected after registration but before first invocation, leading to SIGABRT. It does so by holding strong references to these delegates in the runtime, and adds a device test to exercise the Java → native → managed callback path after forced GC.

Changes:

• Root dynamically created [Export] delegates in AndroidRuntime.AndroidTypeManager to prevent GC collection on CoreCLR.
• Add a new MSBuild device integration test that forces aggressive GC and then invokes an [Export] method through JNI to verify stability.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/Mono.Android/Android.Runtime/AndroidRuntime.cs	Adds a static delegate root list and stores each dynamically-created [Export] callback delegate.
tests/MSBuildDeviceIntegration/Tests/MonoAndroidExportTest.cs	Adds a new device test that forces GC and calls an [Export] method via JNI, validating no crash and expected log output.

[Copilot]

prevent_delegate_gc is a shared mutable List<Delegate> which is appended to from RegisterNativeMembers(). List<T> is not thread-safe; RegisterNativeMembers() can be invoked concurrently for different types, and concurrent Add() calls can corrupt the list or throw, leading to app crashes. Consider protecting the collection with a lock, or switching to a thread-safe collection (e.g., ConcurrentBag<Delegate>), and ensure the chosen approach matches expected access patterns.

[Copilot]

The manifest string uses package="${proj.PackageName}" inside an interpolated string, which will emit a leading $ in the package name (e.g., $com.example...). This produces an invalid manifest package and can cause build/install failures. Use package="{proj.PackageName}" (no $ inside), consistent with other device tests (e.g., DebuggingTest.cs).

[simonrozsival]

@copilot address all review comments

[Copilot]

@copilot address all review comments

Both review comments addressed in abccc78:

1. Thread safety: Added a dedicated prevent_delegate_gc_lock object and wrapped the Add() call in a lock block, consistent with the existing Monitor-based pattern used for sharedRegistrations in the same file.
2. Manifest package name: Removed the erroneous $ prefix from package="${proj.PackageName}" → package="{proj.PackageName}" in the new test, matching the pattern used in DebuggingTest.cs and InstallAndRunTests.cs.