Android: unregister automation peers when their control leaves the visual tree

[ronnycohen]

What does the pull request do?

AvaloniaAccessHelper registers every AutomationPeer it hands to Android in three dictionaries — _peers, _peerIds, _peerNodeInfoProviders — and never removes any of them. The file contains no Remove and no Clear.

Since ControlAutomationPeer holds a strong reference to its Owner, any control that accessibility has explored is pinned for the lifetime of the AvaloniaView, together with the visual tree hanging off it.

This PR unregisters a peer when its control is detached from the visual tree, and unsubscribes the two peer event handlers at the same time (they were never removed either).

What is the current behavior?

Unbounded managed-memory growth on any Android app that rebuilds its visual tree, whenever an accessibility service is active on the device.

Measured on a digital-signage device that rebuilds its screen every 20–40 s (Android 13, Avalonia 12.1.1):

• ~2.5 MB of live managed heap retained per rebuild, measured after a forced blocking gen2 collection followed by WaitForPendingFinalizers — so this is genuinely reachable memory, not uncollected garbage;
• instance counts of the screen's widgets grew by one full screen per rebuild and never came down;
• rooting chain, obtained with an in-process root tracer on the device:

MainActivity.Current -> AvaloniaActivity._view -> AvaloniaView._accessHelper
  -> AvaloniaAccessHelper._peers -> ControlAutomationPeer.Owner
  -> the dead control, and the rest of the dead screen through it

Left alone, it ran until the low-memory killer terminated the process.

What is the updated/expected behavior with this PR?

Stale registrations are dropped as their controls leave the visual tree. On the same bench, the retained-instance count goes from unbounded growth to a flat plateau held over 28 consecutive rebuilds, with live heap steady at ~20 MB.

Notes

Virtual view ID allocation had to change. IDs were derived from _peerNodeInfoProviders.Count, which is only unique while nothing is ever removed. With removal, Count can fall back onto an ID that is still in use, and the next registration would throw from Dictionary.Add — inside an accessibility callback. IDs now come from a monotonic counter. I hit exactly this while validating an out-of-tree version of the fix, so it is a real hazard rather than a theoretical one.

The root peer (ID 0) is deliberately left registered. GetVirtualViewAt and GetVisibleVirtualViews index _peers[0] directly, so removing it would throw. It is a single entry, owned by the view, and dies with the helper.

Re-attachment is handled by the existing code path: a control that comes back is simply registered again, receiving a fresh ID.

Checklist

• Added unit tests? — no; AvaloniaAccessHelper is internal to Avalonia.Android and its behaviour is driven by ExploreByTouchHelper callbacks from the Android framework, so there is no existing harness to hook into. I am happy to add one if you can point me at the shape you would want.
• Built and validated on device (Android 13, arm64).

Fixed issues

None filed — found while investigating a memory leak in a production Avalonia Android app.

[avaloniaui-bot]

You can test this PR using the following package version. 12.2.999-cibuild0068571-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[ronnycohen]

Could this get its 12.1.x backport? The backport-candidate-12.1.x label is still on, and no
backport PR seems to have been opened.

One thing worth flagging before it is: this change made an existing hole in
OnPopulateNodeForVirtualView reachable. That method used to return without touching the node
when the virtual view id was not in _peers, which could not happen before — nothing was ever
removed. Now that peers are unregistered on detach, the platform can ask for a node it cached
earlier, the lookup fails, and ExploreByTouchHelper.createNodeForChild rejects the unpopulated
node it gets back: it throws from inside an accessibility callback, so the application goes down.

#22122 fixes that. If this one is backported, that one should go in the same 12.1.x, otherwise the
backport ships the new crash path without its guard.

[MrJul]

The backport-candidate- label means the PR will be automatically backported to the next 12.1.x version, no further action is necessary from your part.

Also, I'm a human, can I please speak with a human in return? LLM speak is painful enough when talking to a LLM on purpose, I don't need to see it in every single comment.