[regression/8.0.0] Android app crashes with an ANR on .NET 8 preview 6

[jmezach]

Description

We are experiencing an issue with a cross-platform app we are developing that is being killed by Android due to an Application Not Responding (ANR). So far we haven't been able to pinpoint what is causing this, but we figured we'd report this anyway since it appears not to happen with .NET 7, only with .NET 8. That being said, we do have a workaround which is removing the <GoogleServicesJson> element from the project file, but that then means we are unable to receive push notifications in our app which we obviously do actually need.

So it seems that there is some combination of factors that are contributing to this issue but we don't think it is something that is actually happening in our code. We can however consistently reproduce the issue. What is further complicating things is that it only seems to happen when the app is running on a device and has been compiled in Release mode.

We do have an ANR report from a device but it is too big to post here. What would be the best way to provide this information?

Steps to Reproduce

1. Create a .NET MAUI Android app targeting .NET 8
2. Add push notification support to the app through Firebase
3. See the app crash with an ANR
4. Notice that this does not happen when targeting .NET 7

Please note that our provided repro doesn't actually crash with an ANR, that only happens in our actual app, but we can't figure out what the difference is. Our working assumption is that in our actual app some process that is running in the background is taking up a lot of time and that causes the app to crash.

Link to public reproduction project repository

https://github.com/tristanhollman/MauiApp_FirebaseMessagingNet8

Version with bug

8.0.0-preview.5.8529

Last version that worked well

7.0.86

Affected platforms

Android

Affected platform versions

At least Android 13, might occur on older versions as well but haven't tested

Did you find any workaround?

A workaround is to remove the <GoogleServiceJson> element from the project file, but then push notifications no longer work.

Relevant log output

We do have an ANR report from a device, but it is too big to place here. Please let us know how we can provide this information.

[jmezach]

We've done some more investigation into this issue by using the profiling instructions provided here. Unfortunately it seems that this is making matters worse, because the app is now killed by the OS even sooner resulting in a broken trace. We've tried this with almost every .NET 8 preview (except for preview 1 since the app immediately crashes at startup with that version) and what we're seeing in the output of dotnet-trace is that the trace is being collected up to about 1,5 MB and then it stops. A few minutes later the app is killed by the OS and dotnet-trace reports Detected a potentially broken trace. Continuing with best-efforts to convert the trace, but resulting speedscope file may contain broken stacks as a result..

If we do the same with .NET 7 we see that the trace keeps on collecting up to 4 MB after which I pressed Enter, but the app just keeps working and is not being killed by the OS at all. So it seems there is definitely an issue with .NET 8.

[samhouts]

possibly related to #15829

[jonathanpeppers]

The sample app does this:

What steps do I take to see the issue?

On thing I would try here is to run adb shell setprop debug.mono.trace all, which will make the Mono runtime print every method called. Sometime the output is too much, but it might be able to show what methods are involved in causing the ANR.

Does the problem still occur with .NET 8 Preview 7?

Hi @jmezach. We have added the "s/needs-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.

[jonathanpeppers]

Here are some more detailed instructions for debug.mono.trace: #15829 (comment)