[Critical Android Bug] Android views leak via JNI Global Reference even after `DisconnectHandlers()` and explicit peer `Dispose()`

[jozefkosecky]

Description

Description

When repeatedly displaying and destroying a ContentView that contains custom View<T> handlers (specifically a ViewHandler<TVirtual, TPlatform> whose TPlatform is a custom LinearLayout subclass), the native Android View instances are never garbage-collected, even after:

1. Recursive MauiView.DisconnectHandlers() from the root
2. Explicit Java.Lang.Object.Dispose() on the platform view (deferred via Handler.MainLooper.PostDelayed to avoid layout-pass race conditions)
3. View.setBackground(null) to break Drawable callback cycles
4. Multiple GC.Collect() + GC.WaitForPendingFinalizers() cycles
5. ART full GC via adb shell am send-trim-memory <pkg> COMPLETE

Eclipse MAT analysis of the heap dump shows that each leaked native view has GC root: JNI Global, indicating the Mono runtime peer is never released — even when Dispose() was demonstrably called (verified via diagnostic Interlocked counters: scheduled == completed).

Reproduction steps

1. Create a ViewHandler<TElement, CustomLinearLayout> where CustomLinearLayout : LinearLayout is a custom Java type registered via [Register].
2. In ConnectHandler, inflate the platform view and obtain inner views via _root.GetChildAt(i) as ImageView.
3. Open a ContentView page that creates ~15-20 instances of this handler in a Grid.
4. Close the page (via standard MAUI navigation), call view.DisconnectHandlers() recursively, run GC.Collect().
5. Repeat 10×.
6. Force a full ART GC: adb shell am send-trim-memory <pkg> COMPLETE.
7. Take a heap dump: adb shell am dumpheap <pkg> /data/local/tmp/heap.hprof.

Expected behavior

After DisconnectHandlers() + GC + Force ART GC, the native Java View instances should be eligible for collection. dumpsys meminfo Views count should return to baseline.

Actual behavior

After 10 cycles + Force GC:

• dumpsys meminfo Views: 1098 (baseline ~200, so ~900 zombie native Views)
• Heap dump shows ~170 zombie CustomLinearLayout instances with JNI Global GC root path
• Each zombie holds ~5-10 child views (MaterialTextView, AppCompatImageView, etc.) via mChildren
• Per-cycle leak: ~86 native Views, +1.5 MB PSS

Diagnostic evidence

Live count of managed objects (Interlocked counters in ctor/finalizer)

After 10 cycles:

• Form (ContentView): live oscillates 1↔2 ✓ correctly GC'd
• EditableForm (ContentView): live oscillates 2↔4 ✓
• Custom toolbar ContentView: live oscillates 0↔1 ✓
• All managed C# objects ARE finalized correctly.

Eclipse MAT — Path to GC Roots (excluding weak/soft/phantom refs) for one zombie CustomLinearLayout:

CustomLinearLayout @ 0x12d502e8 GC root: JNI Global
 ↓ mChildren View[]
 └ MaterialTextView @ 0x...
 └ MaterialTextView @ 0x...
 └ AppCompatImageView @ 0x...

The only GC root path is JNI Global — meaning Mono runtime holds a global JNI reference that was never released.

Histogram of leaked instances after 10 cycles + Force GC

Class	Instance count
android.graphics.RenderNode	1414
android.view.ViewAnimationHostBridge	1414
androidx.appcompat.widget.AppCompatBackgroundHelper	626
androidx.appcompat.widget.AppCompatTextHelper	455
androidx.emoji2.viewsintegration.EmojiTextViewHelper (5 variants)	454 each
com.google.android.material.textview.MaterialTextView	342
crc6431bef388e7f7f9bd.CustomLinearLayout (custom platform view)	171
mono.android.view.View_OnFocusChangeListenerImplementor	280

Diagnostic counter proof that Dispose() was called

FSK - EnhancedBtn dispose scheduled, total=156
...
FSK - EnhancedBtn dispose completed, total=156

156 platform-view peers explicitly called Java.Lang.Object.Dispose(), yet 171 of them remain in the heap with JNI Global GC root.

Workarounds attempted (none reduced leak)

Attempt	Result
view.DisconnectHandlers() recursively from root	No effect on count
_root.Background = null (break Drawable.callback cycle)	No effect
_image.SetImageDrawable(null)	No effect
_root.OnFocusChangeListener = null	No effect
_root.Dispose() synchronously in DisconnectHandler	Crashes with JNI ERROR (deleted reference) race condition with pending layout pass
_root.Dispose() via View.PostDelayed(200ms)	Sometimes never executes (runnable cancelled when view detached from window)
_root.Dispose() via Handler(Looper.MainLooper).PostDelayed(200ms)	Confirmed runs (verified via counter) — but zombie count unchanged
GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); after disconnect	No effect

The fact that Dispose() runs successfully but the JNI Global Ref persists suggests Mono.Android.ManagedValueManager (or similar internal cache) holds a strong reference to the Mono peer outside the public Dispose() contract.

Environment

• .NET version: 10.0
• Microsoft.Maui.Controls: 10.0.11
• TargetFramework: net10.0-android
• Android API: 34 (emulator + physical Pixel 6 Pro)
• SupportedOSPlatformVersion: 24.0

Heap dump

heap.hprof is attached (51 MB). Filter MAT histogram for crc6431bef388e7f7f9bd.CustomLinearLayout to see the leaked custom platform view; right-click → Path to GC Roots → exclude weak/soft/phantom shows JNI Global as the only GC root.

Impact

• Memory grows ~1.5 MB per page open/close cycle in our app.
• After ~100 cycles the app reaches risky memory pressure on low-end devices.
• Occasional JNI ERROR (deleted reference) crashes occur during teardown when the JNI table is heavily fragmented.

How to capture the diagnostic files (for reproduction)

memory_watch.txt — per-second dumpsys meminfo

Run this PowerShell loop in parallel with the app:

$package = "com.package.xyz" # replace with your package
$out = "$env:USERPROFILE\Desktop\memory_watch.txt"
Remove-Item $out -ErrorAction SilentlyContinue

while ($true) {
 "====================" | Tee-Object $out -Append
 Get-Date | Tee-Object $out -Append

 adb shell dumpsys meminfo $package |
 Select-String "TOTAL PSS|TOTAL RSS|Native Heap|Dalvik Heap|Java Heap|Graphics|Views|Activities|AppContexts|Objects" |
 ForEach-Object { $_.Line } |
 Tee-Object $out -Append

 Start-Sleep -Seconds 1
}

Stop the loop (Ctrl+C) once the 10-cycle reproduction is complete.

heap.hprof — Java heap dump after Force ART GC

$package = "com.package.xyz" # replace with your package

# Step 1: send the app to background so we can request COMPLETE-level trim
adb shell input keyevent KEYCODE_HOME
Start-Sleep -Seconds 2

# Step 2: force a full ART GC (frees everything reachable only via dead refs)
adb shell am send-trim-memory $package COMPLETE
Start-Sleep -Seconds 5

# Step 3: dump the Java heap and pull it locally
adb shell am dumpheap $package /data/local/tmp/heap.hprof
adb pull /data/local/tmp/heap.hprof

# Optional: confirm Views count after Force GC
adb shell dumpsys meminfo $package | Select-String "Views:"

The dump captured this way reflects the post-GC steady state — anything still in the heap is genuinely retained, not waiting for collection. Open heap.hprof in Eclipse MAT (older versions may need hprof-conv heap.hprof heap_std.hprof from Android SDK platform-tools first).

Attached diagnostic files

• memory_watch.txt — output of a script that runs dumpsys meminfo <pkg> once per second over the whole reproduction window. Each block contains TOTAL PSS, Native Heap, Java Heap, and Views count. Shows the linear growth of Views (~86 per cycle) and PSS (~1.5 MB per cycle) across 10 open/close cycles, with no recovery after Force GC.

• heap.zip — zipped Android heap.hprof (51 MB → ~12 MB compressed) captured after the 10-cycle reproduction + adb shell am send-trim-memory <pkg> COMPLETE (full ART GC). Open with Eclipse MAT (must run hprof-conv first if using older MAT versions). Histogram filter crc6431bef388e7f7f9bd.CustomLinearLayout shows the 186 leaked custom platform-view instances; right-click → Merge Shortest Paths to GC Roots → exclude weak/soft/phantom references reproduces the screenshot above.

Eclipse MAT — Path to GC Roots for CustomLinearLayout instances (excluding weak/soft/phantom refs).
All 186 zombie instances have JNI Global as the GC root, holding MaterialTextView and other child views via mChildren.

Minimal reproduction code

The following sanitized excerpts (extracted from our production app) are sufficient to reproduce the leak in a fresh dotnet new maui project. Drop these files into the appropriate folders, register the handler in MauiProgram.cs, then navigate back-and-forth between two pages.

1. Controls/EnhancedButton.cs (MAUI cross-platform control)

using Microsoft.Maui.Controls;

namespace JniLeakRepro.Controls;

// Custom Button subclass with extra bindable properties (icon image + text + description).
// Concrete properties trimmed for brevity.
public class EnhancedButton : Button
{
 public static readonly BindableProperty ImageSourceNameProperty =
 BindableProperty.Create(nameof(ImageSourceName), typeof(string), typeof(EnhancedButton), "");

 public new string ImageSourceName
 {
 get => (string)GetValue(ImageSourceNameProperty);
 set => SetValue(ImageSourceNameProperty, value);
 }
}

2. Platforms/Android/CustomLinearLayout.cs (Java/native subclass)

using Android.Content;
using Android.Util;
using Android.Widget;

namespace JniLeakRepro.Platforms.Android;

// Java type generated as ACW: crc<hash>.CustomLinearLayout
// Hash prefix is what shows up in Eclipse MAT histogram.
public class CustomLinearLayout : LinearLayout
{
 public CustomLinearLayout(Context? context) : base(context) { }
 public CustomLinearLayout(Context? context, IAttributeSet attrs) : base(context, attrs) { }
}

3. Platforms/Android/Resources/layout/EnhancedButton.axml

<?xml version="1.0" encoding="utf-8"?>
<JniLeakRepro.Platforms.Android.CustomLinearLayout
 xmlns:android="http://schemas.android.com/apk/res/android"
 android:orientation="vertical"
 android:layout_width="match_parent"
 android:layout_height="match_parent">
 <ImageView
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:id="@+id/image"/>
 <TextView
 android:layout_width="match_parent"
 android:layout_height="wrap_content"
 android:id="@+id/text"/>
 <TextView
 android:layout_width="match_parent"
 android:layout_height="wrap_content"
 android:id="@+id/description"/>
</JniLeakRepro.Platforms.Android.CustomLinearLayout>

4. Platforms/Android/EnhancedButtonHandler.cs (the handler that leaks)

using Android.Content;
using Android.Views;
using Android.Widget;
using JniLeakRepro.Controls;
using JniLeakRepro.Platforms.Android;
using Microsoft.Maui.Handlers;

namespace JniLeakRepro.Platforms.Android;

public class EnhancedButtonHandler : ViewHandler<EnhancedButton, CustomLinearLayout>
{
 private ImageView? _image;
 private TextView? _text;
 private TextView? _description;
 private CustomLinearLayout? _root;

 public static readonly IPropertyMapper<EnhancedButton, EnhancedButtonHandler> Mapper
 = new PropertyMapper<EnhancedButton, EnhancedButtonHandler>(ViewMapper)
 {
 [nameof(EnhancedButton.Text)] = (h, b) => h.ApplyText(),
 };

 public EnhancedButtonHandler() : base(Mapper) { }

 protected override CustomLinearLayout CreatePlatformView()
 {
 var inflater = Context.GetSystemService(Context.LayoutInflaterService) as LayoutInflater
 ?? throw new InvalidOperationException();
 _root = (CustomLinearLayout)inflater.Inflate(Resource.Layout.EnhancedButton, null)!;
 return _root;
 }

 protected override void ConnectHandler(CustomLinearLayout platformView)
 {
 base.ConnectHandler(platformView);
 // Obtain inner views via GetChildAt - these are auto-wrapped by Mono peers.
 _image = _root!.GetChildAt(0) as ImageView;
 _text = _root!.GetChildAt(1) as TextView;
 _description = _root!.GetChildAt(2) as TextView;
 }

 protected override void DisconnectHandler(CustomLinearLayout platformView)
 {
 base.DisconnectHandler(platformView);
 // Per MAUI docs base.DisconnectHandler nulls handler.PlatformView,
 // but Mono peer for `_root` keeps its JNI Global Ref.
 // Adding `_root.Dispose()` here causes JNI race-crash with pending layout pass.
 }

 void ApplyText()
 {
 if (_text != null) _text.Text = VirtualView?.Text ?? "";
 }
}

5. MauiProgram.cs (handler registration)

builder.ConfigureMauiHandlers(handlers =>
{
 handlers.AddHandler<EnhancedButton, EnhancedButtonHandler>();
});

6. MainPage.xaml (host page with cyclic navigation)

<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
 xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
 xmlns:c="clr-namespace:JniLeakRepro.Controls"
 x:Class="JniLeakRepro.MainPage">
 <Grid x:Name="Root" RowDefinitions="*,Auto" Padding="20">
 <Grid x:Name="ButtonHost" Grid.Row="0" RowSpacing="4"
 ColumnDefinitions="*,*,*,*,*"
 RowDefinitions="*,*,*,*"/>
 <Button Grid.Row="1" Text="Open then close 10x" Clicked="OnRunCycles"/>
 </Grid>
</ContentPage>

7. MainPage.xaml.cs (reproduces the leak)

using Microsoft.Maui.Platform; // for DisconnectHandlers()
using JniLeakRepro.Controls;

namespace JniLeakRepro;

public partial class MainPage : ContentPage
{
 public MainPage() => InitializeComponent();

 async void OnRunCycles(object sender, EventArgs e)
 {
 for (int cycle = 0; cycle < 10; cycle++)
 {
 // Add 20 EnhancedButtons (simulating opening a "doklad" page)
 for (int i = 0; i < 20; i++)
 {
 var btn = new EnhancedButton { Text = $"Btn {i}" };
 Grid.SetRow(btn, i / 5);
 Grid.SetColumn(btn, i % 5);
 ButtonHost.Children.Add(btn);
 }
 await Task.Delay(300);

 // Disconnect all handlers + clear (simulating closing the "doklad")
 foreach (var child in ButtonHost.Children.OfType<View>().ToList())
 child.DisconnectHandlers();
 ButtonHost.Children.Clear();

 GC.Collect();
 GC.WaitForPendingFinalizers();
 GC.Collect();

 await Task.Delay(300);
 }
 }
}

After running OnRunCycles once and then forcing ART full GC + heap dump (commands above), Eclipse MAT will show ~180+ leaked crc<hash>.CustomLinearLayout instances all rooted at JNI Global, with no path back to managed application code.

Suggested fix direction

Either:

1. Java.Lang.Object.Dispose() should reliably remove the peer from JniRuntime.JniValueManager.RegisteredInstances and call JNIEnv.DeleteGlobalRef.
2. MauiContext.Services (or whichever per-page IServiceProvider holds handler references) should be disposed when the page is destroyed, so its strong references to platform views are released.
3. ViewHandler.DisconnectHandler() should also dispose the _platformView peer, not only null the field.

Steps to Reproduce

No response

Link to public reproduction project repository

No response

Version with bug

10.0.20

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

Android

Affected platform versions

All Android versions, that I tried

Did you find any workaround?

No response

Relevant log output

[jozefkosecky]

I've created a minimal reproduction project that isolates the root cause further by testing 4 variants (20 views × 10 cycles each).

Variants tested

Variant	What it tests	Result
A	Built-in MAUI Label (no custom handler)	✅ No leak
B	Custom ViewHandler + plain TextView (no Java subclass)	✅ No leak
C	Custom ViewHandler + CustomLinearLayout subclass, no GetChildAt()	❌ Leaks
D	Same as C + GetChildAt() child peer refs (original repro)	❌ Leaks

Conclusion

Variant C confirms that GetChildAt() child peer refs are not the root cause. The ACW registration of the custom Java subclass alone is sufficient to trigger the leak. Dispose() is confirmed to run (verified via Interlocked counters) but the JNI Global Ref persists regardless.

A plain TextView mapped through a custom ViewHandler (Variant B) does not leak — so the custom handler itself is not the issue either.

Reproduction project

JniLeakRepro.zip

How to run

# Build and deploy
dotnet build -t:Run -f net10.0-android

# Real-time memory monitor (second PowerShell window)
powershell -ExecutionPolicy Bypass -File .\Watch-Memory.ps1

Select a variant in the app, tap Run 10 cycles, and watch the Views count in the monitor. Variants C and D grow ~86 views per cycle with no recovery after GC.Collect() or forced ART GC.

[NafeelaNazhir]

This issue has been validated in Visual Studio 18.5.2 with .NET MAUI versions 9.0.120, 10.0.0-preview1 , 10.0.20, 10.0.60. It can be reproducible on the Android Platform from 10.0.0-preview1.

Screen.Recording.2026-05-07.173300.mp4

[jozefkosecky]

Workaround update — confirms the leak is NOT limited to app-level custom subclasses

After refactoring our production app to eliminate every custom Java.Lang.Object subclass used as TPlatform (replacing them with stock types: LinearLayout, CoordinatorLayout, MauiMaterialButton), the leak rate dropped substantially — but it did NOT disappear. The crash still occurs, just much later.

Numbers before/after the workaround

Metric	Before refactor	After refactor (no app-level ACW classes)
Leak per cycle	~86 native Views	~20 native Views (-77%)
PSS per cycle	~1.5 MB	~0.7 MB (-53%)
Custom app subclasses in heap	171+	0 ✓

Where the remaining leak lives

The crash that finally occurs is still JNI ERROR: deleted reference ... in call to GetObjectClass from void crc6486af4e8104107bae.LayoutViewGroupExt.n_onLayout(...). The CRC-hashed class name crc6486af4e8104107bae.LayoutViewGroupExt is not from our app code — it's the ACW for MAUI's internal Microsoft.Maui.Platform.LayoutViewGroup.

The post-refactor heap dump (after Force ART GC) still shows persistent zombie instances of MAUI-internal ACW classes that the app cannot replace:

• crc6452ffdc5b34af3a0f.LayoutViewGroup (Microsoft.Maui.Platform)
• crc6452ffdc5b34af3a0f.MauiTextView
• crc6452ffdc5b34af3a0f.MauiAccessibilityDelegateCompat
• crc6452ffdc5b34af3a0f.MauiAppCompatEditText
• crc6452ffdc5b34af3a0f.MauiLayerDrawable
• crc645d80431ce5f73f11.MauiCarouselRecyclerView
• crc6486af4e8104107bae.LayoutViewGroupExt
• ... and other MAUI/AndroidX ACW-generated subclasses

[dartasen]

@jozefkosecky It's a bug from dotnet/android

It should be fixed with #11112 #1403 #1410

It's not available in the workload yet, hopefully in few days for the next patch tuesday

[david-j-leigh]

Still reproduces on microsoft.net.sdk.android 36.1.69, and without any MAUI view or handler involved

Adding a data point because dotnet/maui#34879 was closed as fixed in 36.1.69, and I can't find a result posted against that version in this thread.

Environment: .NET SDK 10.0.102, workload set 10.0.111.1, android workload manifest 36.1.69 (confirmed via dotnet msbuild -getProperty:AndroidNETSdkVersion), UseMonoRuntime=true, Android 13 emulator (API 33, x86_64).

The repro needs no MAUI views, handlers or navigation

My app does embed MAUI, but the leaking type is a plain AppCompatActivity — not a MauiAppCompatActivity — and the trigger is simply device rotation:

adb shell settings put system accelerometer_rotation 0
adb shell settings put system user_rotation 1 # alternate 1 / 0
adb shell dumpsys meminfo <pid> # Objects -> Activities

after	Activities
launch	1
2 rotations	3
4 rotations	5
6 rotations	7
8 rotations	9
10 rotations	11

Exactly one Activity leaked per rotation, linear, never recovered. Identical slope on 36.1.2 and 36.1.69.

This lines up with @jozefkosecky's Variant C conclusion that ACW registration alone is sufficient to trigger it: an Activity is an ACW type (crc64….MainActivity), and there is no custom handler, no custom TPlatform, and no MAUI view in this path at all.

At scale it is fatal. An automated UI suite that rotates roughly twice per test ends a 33-test class holding 72 Activities and 7,466 Views behind a single ViewRootImpl, and a longer run dies with:

java.lang.OutOfMemoryError: Failed to allocate ... growth limit 201326592

i.e. the 192 MB Java heap exhausted, after ~240 tests.

Same root signature as reported here

• Every leaked Activity is its own GC root: JNI global.
• The managed peers are unreachable — a .gcdump shows no managed referrer at all for the leaked MainActivity, nor for the OnBackPressedDispatcher peers leaking alongside it.
• Forced managed GC released 63 of 1,877 global refs and 0 Activities.
• am send-trim-memory RUNNING_CRITICAL / COMPLETE ×3: no change.

One mechanism observation I haven't seen mentioned

With debug.mono.log=gref, across 51,461 gref log lines, gwrefc is 0 in every single one.

Global references are being released in general (15,797 created, 13,920 destroyed over the session), so the ordinary path works. But no peer is ever transitioned to a weak global reference — the step used to test Java-side reachability before collecting. Whatever reclaims the ordinary peers never appears to run that test on these.

Things that did not help

• MONO_GC_PARAMS=bridge-implementation=… — default (tarjan) and new behave identically. old is rejected at startup: "The 'old' bridge processor implementation is no longer supported, falling back to the 'new' bridge." Note that debug.mono.env appears to be ignored on this runtime; the setting only took effect via an AndroidEnvironment file.
• Removing app-side references. Three separate fixes each provably removed a real reference — heap dumps confirm the target went from JNI-global-rooted to unrooted in each case — and each moved the Activity count by zero. The root simply relocated, ending at the Activity's own runtime-created peer, which no application code creates and none can remove.

[dartasen]

@david-j-leigh As the original issues are closed and locked. Maybe you could recreate an issue on dotnet/android so the android team could give it a look again (cc @jonathanpeppers)

[jonathanpeppers]

This looks very similar to:

• Memory Leak Switching Activities #12253 (comment)

^^ This one, we didn't find a problem except in the sample the GC didn't run often enough. A manual GC.Collect() call "fixed" it.

But I will investigate the repro above.