Infinite ANR loop in MAUI UI with Android 13

[WMLPB]

Description

Hi all,

we developed an inhouse logistics app in Xamarin Forms for our Android based barcode scanners and ported it to MAUI recently. Those barcode scanners are usually quite expensive but low on processor power and RAM. Our older devices used to run on older versions of Android, now we got the first barcode scanners with Android 13.

On those new devices I suddenly get an "Application is not responding" ANR message by just using the UI. Important: We do no work on the UI-Thread, we load our data with Tasks. The ANR happens on MAUIs side, as far as I can tell. I discovered two main scenarios so far – creating a new Page and scrolling the CollectionView:

var page = new SettingsPage();

This SettingsPage has got no code behind, but more than 20 controls on it – Labels, Checkboxes and RadioButtons. It is just XAML with data binding. So I guess, the ARN must happen in InitializeComponent(). And: I can circumvent this ANR by creating all my Pages at application startup – inside the constructor of MainPage.xaml.cs – and then just navigating to them with Navigation.PushAsync(settingsPage).

For the second scenario I do not have any workaround. The CollectionView is very laggy when scrolling. It is just a list with a few hundred items – an Image and a Label. The CollectionView hangs after scrolling up / down for five or six items and the ANR shows up.

And now comes the very annoying part – probably a bug by Google in Android 13, but I don’t know: After the first ANR shows up, I get following ANRs every five seconds. I can click "Wait" as often as I want, the next ANR is five seconds away. There is no way to stop those ANRs – only to click on "Close App". So – after the first ANR shows up, our users have to close the app and restart it – only to get the next infinite ANR loop just by scrolling the CollectionView.

What can I do? We start a new project for a big international customer soon, we need to order new devices and we need our app working urgently. Please – do not put this issue on your backlog! And I'm sorry, I can't create a repository to reproduce this issue.

Thank you very much for help.

Steps to Reproduce

1. Create a new Page
2. Scroll the CollectionView

Link to public reproduction project repository

No response

Version with bug

8.0.7 SR2

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

Android 13

Did you find any workaround?

No response

Relevant log output

No response

[jfversluis]

Please – do not put this issue on your backlog! And I'm sorry, I can't create a repository to reproduce this issue.

I understand your situation, but hopefully you can also understand our point of view.

You already mention that this is unlikely a bug in the .NET MAUI codebase, or at least you're not sure. And then without seeing any code, or logs or anything apart from your description, it is very hard to diagnose this problem. So even if we did want to help you out, its impossible to actually do so with the information we have right now.

A reproduction sample is not just handing over your proprietary code, its extracting the problematic code into a separate project so that a) you for yourself can understand all the moving parts that make up for this issue and maybe understand better if its something in your code or ours and b) we can easily see those same moving parts, diagnose and hopefully come with a resolution quickly.

As much as I want to help you (and anyone) regardless of this being a bug on our side or not, we're quite busy as it is and its hard to justify spending time to try and recreate your situation and then even maybe find out that this is something in Android or in your own code.

I'd like you to please to some more investigation (comment out pieces of code to see differences, run on different Android versions, try to replace a control with an alternative) and document those here as well as gather logs and try to really get that reproduction project.

Thanks!

[Vroomer]

Does it happen in release mode without debugger? ANR is common behavior during debugging (including consecutive warnings every few seconds) and can be disabled: https://stackoverflow.com/questions/33111495/disable-anr-messages-while-debugging.

Is it device specific?

Slow CollectionView sounds also a lot like a behavior of debug mode as there is Interpreter doing extra work for Hot Reload.

Furthermore you mention that you load data in Tasks, but async Task doesn't prevent the work to be done on UI-Thread. It just prevents UI-Thread to be blocked during I/O operations. You have to specifically Run CPU heavy tasks on ThreadPool.

As for the release mode performance, CollectionView can be greatly optimized by following:

• Set height of ItemTemplate to be fixed and set CollectionView mode to measure only first item.
• Make ItemTemplate layout as flat as possible (no nesting).
• You can set Layouts to be compressed if you don't use VisualElement properties on them.
• Don't use "Auto" in Grid and try to keep Heights fixed.
• Always use compiled bindings.
• Try to stay away from Converters and OneWay/TwoWay Bindings.
• Make sure CollectionView has or inherits fixed size. Don't nest CollectionView in ScrollView.

[WMLPB]

Hi Vroomer,

Thank you very much for your kind reply. It happens in release mode on the actual device. I think it is not device specific per se, but it depends on processor speed and RAM on the device.

My Settings-ViewModel has got some Boolean properties like this:

        public bool ShowSearch
        {
            get
            {
                return _showSearch;
            }
            set
            {
                if (_showSearch != value)
                {
                    _showSearch = value;
                    Preferences.Set("SHOW_SEARCH", value);
                    OnPropertyChanged(nameof(ShowSearch));
                }
            }
        }

These are data bound to CheckBoxes on the SettingsPage. There is no code behind. When I create the SettingsPage by

var page = new SettingsPage();

only the constructor and InitializeComponent() is called:

        public SettingsPage()
        {
            InitializeComponent();
        }

I removed all controls for testing and added them back one by one. From a certain amount of controls on, InitializeComponent() takes to long and the ANR shows up. Frankly, I think Microsoft.Maui.Controls.Xaml.Extensions.LoadFromXaml() blocks the UI-Thread for too long.

Thank you very much for your checklist.

• The ItemTemplate has got a fixed height. But if I measure only the first item, all other items but the first one do not react to layout changes anymore (IsVisible / IsEnabled).
• My layout is very simple: An image (fixed height, low resolution) and a Label.
• I tried compressed layouts to no benefit, sorry.
• I use compiled bindings; I have eliminated all warnings to compiled bindings.
• I do not use Converters, use only OneWay bindings
• My CollectionView is inside a *-GridRow

The ANR does not happen while I am loading the data. It happens, as soon as I start scrolling the CollectionView. We are evaluating a third party CollectionView from a component developer at the moment. In their CollectionView the scrolling is smooth and I have no ANR so far.

Gerald, thank you very much for your reply, too. I understand your point of view, but I am sorry, I cannot provide a repository with my company account. We do not use Github, company policy. I tested a small public repository, but it shows sensible information on the internet.

The infinite ANR loop may be a bug by Google – but the initial ANR is in LoadFromXaml and inside of the MAUI-CollectionView.

[Vroomer]

If the third party CollectionView works for you, maybe it's an issue with virtualization of MAUI CollectionView or just different recycling strategy that is more CPU/memory intense. If you are interested, there is an experimental alternative to CollectionView that you can customize and play with: https://github.com/Redth/Maui.VirtualListView - it's made by Redth, the Engineering Lead Principal of MAUI.

[PureWeen]

@WMLPB this might help
https://learn.microsoft.com/en-us/xamarin/android/deploy-test/debugging/android-debug-log?tabs=windows

But I don't know if we'll be able to do much with a repro.

We have some fixes coming in SR4 that might help?

[WMLPB]

Hi Vroomer, hi PureWeen,

Thank you very much for your replies. I’ll have a look into VirtualListView – and I’ll create an android device log this week. What I figured out so far is, that if I target Android 9 with my app on the Android 13 device, I don’t get the initial ANR when scrolling the CollectionView. As soon as I target Android 10 or above, the initial ANR is back.

[PureWeen]

This might be resolved by
#22347

[PureWeen]

Can you test with the latest nightly build?
https://github.com/dotnet/maui/wiki/Nightly-Builds

[dotnet-policy-service]

Hi @WMLPB. 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.

[dotnet-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

[WMLPB]

Hi PureWeen,

I’m sorry for my late reply. Thank you very much for your help. It is much appreciated. I’ve implemented a work around for my app – I create all pages at initialisation of my MainPage at application start up and then just call Navigation.PushAsync(settingsPage). For the CollectionView I created an AndroidEnvironment env.conf file with the following setting:

MONO_GC_PARAMS=bridge-implementation=tarjan,nursery-size=128m,soft-heap-limit=512m

Thanks again.