SIGSEGV: null jobject/jmethodID passed to CallObjectMethodA from CoreCLR JIT code (not #10910 - marshal methods are already off)

### Android framework version

net11.0-android (Preview)

### Affected platform version

.NET 11.0.100-preview.7.26381.103 / .NET MAUI 11.0.0-preview.7.26406.9

### Description

A .NET MAUI BlazorWebView app segfaults on the main thread inside a JNI call made from managed code. `Cause: null pointer dereference`, and both the object and method registers are zero.

```
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000004 (read)
Cause: null pointer dereference
x21 0000000000000000 x22 0000000000000000 x25 0000000000000000
backtrace:
#00 art::JValue art::InvokeVirtualOrInterfaceWithJValues(...) libart.so
#01 art::JNI::CallObjectMethodA(_JNIEnv*, _jobject*, _jmethodID*, jvalue const*)+184 libart.so
#02 /memfd:doublemapper (deleted) (offset 0x3221000)
```

Frame #02 is the CoreCLR JIT's W^X double-mapped code region, so this is managed code calling `CallObjectMethodA` with a null `jobject` or `jmethodID`.

**This is not #10910.** That issue has a very similar tombstone — same signal, same cause, `x21`/`x22` both zero — but is attributed to `AndroidEnableMarshalMethods` being on, and its workaround is to turn it off. In this app the property evaluates to `False` already:

```
$ dotnet msbuild App.Maui.csproj -p:TargetFramework=net11.0-android -getProperty:AndroidEnableMarshalMethods
{ "Properties": { "AndroidEnableMarshalMethods": "False" } }
```

The other differences: #10910 is .NET 10 on Mono with AOT; this is .NET 11 preview 7 on CoreCLR (hence `doublemapper` rather than a Mono region), and the fault address is `0x4` rather than `0x0`.

**Context.** The crash lands 1.06 s into re-initializing the Blazor app after a WebView reload — a window with unusually heavy JNI traffic, since the whole MAUI/Blazor object graph is torn down and rebuilt while the WebView is being recreated:

```
15:46:21.287 new app scope created
15:46:21.414 AppScopedServiceStarter: -> PrepareFirstRender
15:46:22.475 SIGSEGV
15:46:23.036 process died
```

I can't attribute it to a specific call — the backtrace has only three frames and none of them name a managed method.

**Possibly related.** The same device produced two other native crashes in the same subsystem within three days, with a different signature: `Scudo ERROR: invalid chunk state when deallocating` from `xamarin::android::TypeMapper::java_to_managed`, on Chromium WebView thread-pool threads. Filed separately. A null JNI handle here and an invalid free there are both consistent with JNI peer/handle lifetime going wrong, but I have no evidence tying them together beyond the subsystem.

### Steps to Reproduce

I don't have a minimal repro. This is a production crash: four native crashes in three days on one device, across two installed builds of the same app.

The shape of the app, since that's the best lead I can offer:

1. .NET MAUI, `net11.0-android`, CoreCLR, targetSdk 37, `AndroidEnableMarshalMethods` off.
2. UI is a `BlazorWebView`, with sustained JNI traffic: audio capture and playback, a foreground service, Firebase messaging, and continuous WebView JS interop.
3. The crash window is a full Blazor app teardown and rebuild inside the live process — old scope disposed, `MauiWebView` recreated, new scope built — triggered by the app recovering from a lost render batch.

Collect with `adb shell dumpsys dropbox --print data_app_native_crash`.

### Did you find any workaround?

No. `AndroidEnableMarshalMethods=false` — the workaround for the similar-looking #10910 — is already in effect here.

### Relevant log output

```shell
*** Tombstone ***

Build fingerprint: 'samsung/m3quew/m3q:16/BP4A.251205.006/S948U1UES4AZG3_OYM4AZG3:user/release-keys'
Kernel Release: '6.12.30-android16-5-pd30ff70-abogkiS948USQS4AZG3-4k'
ABI: 'arm64'
Timestamp: 2026-08-20 15:46:22.475075674-0700
Process uptime: 6776s
Cmdline: chat.actual.app
pid: 24089, tid: 24089, name: chat.actual.app >>> chat.actual.app <<<
tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY)
esr: 0000000092000006 (Data Abort Exception 0x24)
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000004 (read)
Cause: null pointer dereference
x0 0000000002569b78 x1 0000000000027562 x2 0000000070a30bb0 x3 0000000000000000
x4 00000075b7a99290 x5 0000007ff4a5bd18 x6 0000006ed4832b20 x7 000000002000000e
x8 0000000000000002 x9 000000006f96af60 x10 000000006f7b7088 x11 000000000000001c
x12 000000006f8137a0 x13 0000007442569e78 x14 0000006edd1031e8 x15 0000000400000002
x16 00000075b802faa0 x17 00000075b76f7798 x18 0000000000000007 x19 0000007ff4a5bc80
x20 0000000000027562 x21 0000000000000000 x22 0000000000000000 x23 0000000070a30bb0
x24 00000078a4b614c0 x25 0000000000000000 x26 0000000000000002 x27 0000000070a30bb4
x28 0000000002321aa8 x29 0000007ff4a5bbf0
lr 00000075b7682180 sp 0000007ff4a5bb20 pc 00000075b76821e4 pst 0000000060001000
esr 0000000092000006
3 total frames
backtrace:
#00 pc 00000000002821e4 /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAcc...)
#01 pc 0000000000699348 /apex/com.android.art/lib64/libart.so (art::JNI::CallObjectMethodA(_JNIEnv*, _jobject*, _jmethodID*, jvalue const*)+184)
#02 pc 00000000001a65b4 /memfd:doublemapper (deleted) (offset 0x3221000)

*** Surrounding app log ***

15:46:21.287 AppUIHub [+] #4
15:46:21.414 [@trace] AppScopedServiceStarter: 6,773.762s -> PrepareFirstRender
15:46:22.320 F libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4 in tid 24089 (chat.actual.app), pid 24089
15:46:22.970 DropBoxManagerService: add tag=data_app_native_crash
15:46:22.973 ActivityManager: crash : chat.actual.app,10376
15:46:23.036 ActivityManager: Process chat.actual.app (pid 24089) has died
```

Start with the supplied tombstone and collect comparable crashes using `adb shell dumpsys dropbox --print data_app_native_crash`; compare the JNI call path with #10910 while keeping `AndroidEnableMarshalMethods=false`. Focus on the BlazorWebView teardown and rebuild window, and consider the issue resolved when the null `jobject` or `jmethodID` path is identified and a reliable fix or reproduction is established.

Written by the indexing model from the issue text.