JnienvArrayMarshaling.GetObjectArray fails on CoreCLR with emulator 36.4.10

[jonathanpeppers]

Description

Android.RuntimeTests.JnienvArrayMarshaling.GetObjectArray consistently fails on CoreCLR (Release) when running on Android emulator 36.4.10 (previously passing on emulator 32.1.9).

The test passes on MonoVM and NativeAOT — only CoreCLR is affected.

Error

Expected: True
But was: False

The assertion comes from AssertArrays which lacks diagnostic output, so we don't know what values CoreCLR returns.

Repro

• Emulator: 36.4.10 (package 15004761)
• Runtime: CoreCLR
• Test: tests/Mono.Android-Tests/Mono.Android-Tests/Android.Runtime/JnienvArrayMarshaling.cs line 267

Context

Discovered in #10971 (emulator bump PR). The test was ignored on CoreCLR to unblock the emulator update.

Next Steps

1. Add diagnostic output to GetObjectArray / AssertArrays to understand what values come back
2. Investigate CoreCLR-specific JNI array marshaling difference with newer ART runtime

[simonrozsival]

This is very interesting! I wonder if it's just running with the new emulator, or because of running on API 36.

[simonrozsival]

Investigation update

I spent time investigating this locally with emulator 36.4.10 installed at ~/Projects/emulator.

What I tested

Config	API	Emulator	ABI	Mono.Android source	Result
Release	29	36.4.10	arm64	Released .NET 10 SDK	✅
Release	36	36.4.10	arm64	Released .NET 10 SDK	✅
Debug	29	36.4.10	arm64	Source-built (preview.1)	✅
Debug	36	36.4.10	arm64	Source-built (preview.1)	✅

Key observations

1. Not reproducible locally with either API 29 or API 36
2. The CI failure was in Release mode — I could only test Debug from source (no local Release build). Release enables trimming + R2R which could affect IConvertible resolution or peer management in ManagedValueManager
3. CI may use x86_64 emulator (Intel Mac agents) vs my arm64 — this could matter for JNI marshaling
4. The diagnostic output (from the test) confirms the marshaling works correctly on arm64: byte array reads correctly, ReferenceEquals returns true, values[1] is int is true

Diagnostic PR

Created #10975 with improved assertion messages and JNI diagnostic logging. The CI run on that PR should capture the exact failure point if it reproduces in the Release/x86_64 CI environment.

Code path analysis

The GetObjectArray flow: GetConverter selects converter by JNI class name → IJavaObject converter → PeekPeer (identity hash lookup in ManagedValueManager for CoreCLR). The most likely failure point is Assert.IsTrue(object.ReferenceEquals(values[0], Application.Context)) if PeekPeer fails to find the existing peer and CreatePeer makes a new instance.

[simonrozsival]

Update: Cannot reproduce on arm64 — likely x86_64 specific

After building the full repo from source (make prepare && make all CONFIGURATION=Release), I ran the Release CoreCLR test on emulator 36.4.10:

Config	API	Emulator	ABI	Build	Result
Release (source, trimmed)	29	36.4.10	arm64	Source-built from main	✅ 873 passed, 0 failed
Debug (source)	29	36.4.10	arm64	Source-built from another worktree	✅ 868 passed
Debug (source)	36	36.4.10	arm64	Source-built from another worktree	✅ 868 passed

The Release CoreCLR test passes on arm64.

The CI uses Intel Mac hosted agents which run x86_64 emulators. This bug may be specific to the x86_64 ABI — possibly a JNI marshaling difference in the x86_64 ART runtime on emulator 36.

The diagnostic PR #10975 will capture the exact failure when CI runs it on x86_64.