Potential ANR / GC regression in .NET 10 Android compared to .NET 9

[dbSoft-SoftwareSolutions]

Android framework version

net10.0-android

Affected platform version

Vs2026 net10

Description

We are seeing a significant increase in ANRs after moving our Android app from .NET 9 to .NET 10.

The same application and usage pattern appears stable on .NET 9, but when targeting .NET 10 we start receiving frequent ANR reports in Google Play Console.

Important detail:
Crashlytics does not report corresponding fatal crashes. The app appears to freeze / become unresponsive rather than crash with an uncaught exception.

Observed behavior:

• .NET 9 Android build: ANRs are gone or extremely rare
• .NET 10 Android build: ANRs return frequently
• Same app logic
• Same user workflow
• Same devices / customers
• No matching Crashlytics crashes

ANR traces often include native/runtime/GC related frames such as:

• art::gc::collector::ConcurrentCopying
• Runtime.gc
• libart.so
• Android Runtime / GC activity

App context:

• Android POS / hospitality application
• Built with C# / .NET for Android
• Uses multiple Activities
• Heavy UI rendering in some screens
• Uses FFImageLoading / SVG image rendering and caching
• ANRs appear sporadic, not always reproducible locally

We already tested disabling several build/runtime optimizations:

false None false false

These changes did not eliminate the ANRs in .NET 10.

Additional observations:

• Adding more awaits / avoiding synchronous UI-heavy operations reduced ANRs, but did not fully explain the difference between .NET 9 and .NET 10.
• The strongest signal is that .NET 9 behaves normally while .NET 10 produces ANRs under similar real-world usage.

Could there be a runtime / GC / Android workload regression in .NET 10 that could cause longer stalls or ANRs compared to .NET 9?

What diagnostic information would be most useful for us to provide?

Steps to Reproduce

1. Build and deploy the application using .NET 10 for Android in Release mode.
2. Use the application under normal production workload:
   • frequent Activity navigation
   • image rendering
   • SVG/image caching
   • async network/database operations
3. Leave the application running during real-world usage for extended periods.
4. After some time, Android starts reporting ANRs in Google Play Console.

Observed result:

• ANRs occur sporadically
• ANR traces frequently contain GC/runtime related frames:
  • art::gc::collector::ConcurrentCopying
  • Runtime.gc
  • libart.so
• Firebase Crashlytics does not report matching fatal crashes.

Important comparison:

• Rebuilding the same application on .NET 9 significantly reduces or eliminates the ANRs under the same workload and devices.

Did you find any workaround?

No response

Relevant log output

Most of errors contains Mediatek MT6769 processor

error1.txt
error2.txt

[jonathanpeppers]

Do you have a sample project (or at least a log) that shows the crash?

We'd need some details like an exception, call stack, etc.

[dbSoft-SoftwareSolutions]

Hi @dbSoft-SoftwareSolutions. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

I have attached two ANR reports and a few screenshots from Google Play Console.

Please let me know if you need any additional information or diagnostics.

[jonathanpeppers]

Here is copilot's initial assessment:

Root Cause Analysis
The mechanism (from both ANR traces)

Error 1: Main thread blocked in Runtime.gc() → MarkCompact::CompactPage (ART GC compaction), called from libmono-android.release.so via the Mono GC bridge (OSBridge::java_gc).
Error 2: Main thread blocked in NewGlobalRef via OSBridge::take_global_ref_jni — the GC bridge converting weak refs back to global refs after Java GC.

Both originate from Mono SGen's gc_cross_references callback (osbridge.cc:998), which runs synchronously on whatever thread triggered the GC. When the main/UI thread triggers a nursery collection, the
entire bridge processing — including calling Runtime.gc() on ART — blocks the UI thread.

PR dotnet/runtime#121247 "Make color visible to client permanent" was backported to release/10.0 (#121483) but has no release/9.0 backport. This is the .NET 10-only change that explains the regression.

What it does
The Tarjan bridge marks non-bridge SCCs as "visible to client" when xrefs_in * xrefs_out > 60. Previously, subsequent xref deduplication could reduce that count and make the SCC invisible again. The fix
pins the flag — once visible, always visible.

Why this causes ANRs in .NET 10 but not .NET 9

• .NET 9: SCCs can lose visible_to_client during processing → fewer SCCs passed to gc_cross_references_cb → less work during bridge processing → fits within ANR deadline on low-end hardware
• .NET 10: SCCs stay visible once flagged → more SCCs passed to gc_cross_references_cb → more take_global_ref_jni calls + longer Runtime.gc() → exceeds the 5-second ANR deadline on MediaTek MT6769

The additional Tarjan changes also only in .NET 10 (#114637 can_reduce_color init fix, #115049 bridge comparison) likely compound the effect.
This belongs in dotnet/runtime as a performance regression in sgen-tarjan-bridge.c.

I asked it to also check dotnet/android, but copilot didn't find a specific change that happened in .NET 10 that was concerning.

@dbSoft-SoftwareSolutions does MONO_GC_PARAMS=bridge-implementation=old change anything here?

@BrzVlad is there another setting we could try here, to help diagnose?

[dbSoft-SoftwareSolutions]

Here is copilot's initial assessment:

Root Cause Analysis
The mechanism (from both ANR traces)

Error 1: Main thread blocked in Runtime.gc() → MarkCompact::CompactPage (ART GC compaction), called from libmono-android.release.so via the Mono GC bridge (OSBridge::java_gc).
Error 2: Main thread blocked in NewGlobalRef via OSBridge::take_global_ref_jni — the GC bridge converting weak refs back to global refs after Java GC.

Both originate from Mono SGen's gc_cross_references callback (osbridge.cc:998), which runs synchronously on whatever thread triggered the GC. When the main/UI thread triggers a nursery collection, the
entire bridge processing — including calling Runtime.gc() on ART — blocks the UI thread.

PR dotnet/runtime#121247 "Make color visible to client permanent" was backported to release/10.0 (#121483) but has no release/9.0 backport. This is the .NET 10-only change that explains the regression.

What it does
The Tarjan bridge marks non-bridge SCCs as "visible to client" when xrefs_in * xrefs_out > 60. Previously, subsequent xref deduplication could reduce that count and make the SCC invisible again. The fix
pins the flag — once visible, always visible.

Why this causes ANRs in .NET 10 but not .NET 9

• .NET 9: SCCs can lose visible_to_client during processing → fewer SCCs passed to gc_cross_references_cb → less work during bridge processing → fits within ANR deadline on low-end hardware
• .NET 10: SCCs stay visible once flagged → more SCCs passed to gc_cross_references_cb → more take_global_ref_jni calls + longer Runtime.gc() → exceeds the 5-second ANR deadline on MediaTek MT6769

The additional Tarjan changes also only in .NET 10 (#114637 can_reduce_color init fix, #115049 bridge comparison) likely compound the effect.
This belongs in dotnet/runtime as a performance regression in sgen-tarjan-bridge.c.

I asked it to also check dotnet/android, but copilot didn't find a specific change that happened in .NET 10 that was concerning.

@dbSoft-SoftwareSolutions does MONO_GC_PARAMS=bridge-implementation=old change anything here?

@BrzVlad is there another setting we could try here, to help diagnose?

Thank you for the detailed analysis.

I will prepare a test build using:

MONO_GC_PARAMS=bridge-implementation=old

and deploy it to affected devices/customers to see whether it changes the ANR behavior.

Please note that the ANRs are sporadic and mostly observed through Google Play Console in real-world production usage, so I may need some time before I can confirm the results.

I will report back with:

• whether the build works correctly with this setting
• whether the ANR frequency changes
• any new ANR traces from the test build

Just to confirm, for .NET 10 Android, should I provide this through an environment file via:

or directly as a raw value inside the .csproj file?
Example:

<PropertyGroup>
    <AndroidEnvironment Include="MONO_GC_PARAMS=bridge-implementation=old" />
</PropertyGroup>

I want to make sure I am testing it the correct way.

If there are any additional GC/bridge-related settings you would like me to test, please let me know.

[BrzVlad]

Copilot's analysis doesn't make any sense. Without the referenced fix, if you get to the situation where there are fewer colors visible to client in the final computation, the GC doesn't suddenly report fewer SCCs to java (and obtains magically better performance), the app just immediately crashes instead.

Are you running on recent .net 10 ? 10.0.6 had some fixes for general stability.

MONO_GC_PARAMS=bridge-implementation=old was removed quite some time ago. You can try MONO_GC_PARAMS=bridge-implementation=new instead. Also you can disable concurrent GC via <AndroidEnableSGenConcurrent>False</AndroidEnableSGenConcurrent>. These are options impacting the mono .NET Runtime. You could also try to use CoreCLR runtime instead <UseMonoRuntime>false</UseMonoRuntime>, since we will transition to it starting in .net11. Note that it currently doesn't have support on arm, just arm64. I would highly recommend this option instead, since we are trying to get more customers to try it out anyway.

Looking at the stacktraces, they don't point to anything in our runtime so it is not clear at all what the problem is. Maybe the android gc does actually take too long. What I used in the past to set env vars is:

<ItemGroup>
    <AndroidEnvironment Include="Platforms\Android\Environment.txt" />
</ItemGroup> 

Then in the that file you have pairs like:

MONO_GC_PARAMS=bridge-implementation=new
MONO_LOG_MASK=gc
MONO_LOG_LEVEL=debug

If these work as expected, you would get various logs from our GC (various entries with GC_MINOR, GC_MAJOR ..). Android runtime should print independently their own GC activity to logcat as well. I would run the app locally and obtain these logs locally to see if the app exhibits some unreasonable GC activity/suspend in some critical UI paths, indicating that it could lead to ANRs on some devices.

[dbSoft-SoftwareSolutions]

Copilot's analysis doesn't make any sense. Without the referenced fix, if you get to the situation where there are fewer colors visible to client in the final computation, the GC doesn't suddenly report fewer SCCs to java (and obtains magically better performance), the app just immediately crashes instead.

Are you running on recent .net 10 ? 10.0.6 had some fixes for general stability.

MONO_GC_PARAMS=bridge-implementation=old was removed quite some time ago. You can try MONO_GC_PARAMS=bridge-implementation=new instead. Also you can disable concurrent GC via <AndroidEnableSGenConcurrent>False</AndroidEnableSGenConcurrent>. These are options impacting the mono .NET Runtime. You could also try to use CoreCLR runtime instead <UseMonoRuntime>false</UseMonoRuntime>, since we will transition to it starting in .net11. Note that it currently doesn't have support on arm, just arm64. I would highly recommend this option instead, since we are trying to get more customers to try it out anyway.

Looking at the stacktraces, they don't point to anything in our runtime so it is not clear at all what the problem is. Maybe the android gc does actually take too long. What I used in the past to set env vars is:

<ItemGroup>
    <AndroidEnvironment Include="Platforms\Android\Environment.txt" />
</ItemGroup> 

Then in the that file you have pairs like:

MONO_GC_PARAMS=bridge-implementation=new
MONO_LOG_MASK=gc
MONO_LOG_LEVEL=debug

If these work as expected, you would get various logs from our GC (various entries with GC_MINOR, GC_MAJOR ..). Android runtime should print independently their own GC activity to logcat as well. I would run the app locally and obtain these logs locally to see if the app exhibits some unreasonable GC activity/suspend in some critical UI paths, indicating that it could lead to ANRs on some devices.

Thank you for the clarification and detailed explanation.

The affected builds are currently running on .NET 10, but I will verify the exact SDK/workload version and make sure I test on the latest available 10.0.x version as well.

For the initial testing, I will proceed step-by-step rather than combining multiple runtime changes together, so that I can better isolate the impact of each setting.

I will first test:

<PropertyGroup>
    <AndroidEnableSGenConcurrent>False</AndroidEnableSGenConcurrent>
</PropertyGroup>

If the ANRs continue, I will then separately test the environment configuration approach you suggested using:

<ItemGroup>
    <AndroidEnvironment Include="Platforms\Android\Environment.txt" />
</ItemGroup>

with:

MONO_GC_PARAMS=bridge-implementation=new

I will also prepare a separate arm64-only CoreCLR test build later using:

<PropertyGroup>
    <UseMonoRuntime>false</UseMonoRuntime>
</PropertyGroup>

since that could help determine whether the issue is Mono-runtime specific.

Additionally, I will try to capture local GC/runtime logs with:

MONO_LOG_MASK=gc
MONO_LOG_LEVEL=debug

and compare them with Android Runtime GC activity from logcat around heavy UI/image rendering paths.

I will report back with the results once I gather enough production/runtime data.

[BrzVlad]

I just remembered that the log enabling might not be doable from the env vars. You might have to set these properties instead via adb, before running the app:

adb shell setprop debug.mono.log mono_log_level=debug,mono_log_mask=gc