[Android] Shell: Fix fragment teardown crash - #37048
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 923e744a-f52b-46ce-939e-b6d27d4f5287
|
Azure Pipelines: Successfully started running 1 pipeline(s). There may be pipelines that require an authorized user to comment /azp run to run. |
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 37048Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 37048" |
|
/azp run maui-pr-devicetests |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
/azp run maui-pr-uitests, maui-pr-devicetests |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
This PR addresses an Android Shell crash during fragment teardown by avoiding premature disposal of managed fragment wrappers that are still owned by AndroidX FragmentManager, preventing native-to-managed callbacks (e.g., OnDestroyView/OnDestroy) from running after the managed peer has been disposed.
Changes:
- Stop explicitly disposing
_wrapperFragmentinShellItemHandlerAdapter.Dispose(), relying onFragmentManagerto dispose the fragment at the correct lifecycle point. - Stop explicitly disposing
_wrapperFragmentinShellSectionHandlerAdapter.Dispose()for the same reason. - Add clarifying comments documenting the lifecycle/ownership rationale.
Show a summary per file
| File | Description |
|---|---|
| src/Controls/src/Core/Handlers/Shell/ShellItemHandler.Android.cs | Removes _wrapperFragment?.Dispose() from ShellItemHandlerAdapter.Dispose() and documents why fragment disposal must be left to FragmentManager. |
| src/Controls/src/Core/Handlers/Shell/ShellSectionHandler.Android.cs | Removes _wrapperFragment?.Dispose() from ShellSectionHandlerAdapter.Dispose() and documents why fragment disposal must be left to FragmentManager. |
Copilot's findings
- Files reviewed: 2/2 changed files
- Comments generated: 0
|
@PureWeen I checked the targeted Android Helix results. The original |
Note
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!
Description
Preview 7 Android Mono Controls device tests repeatedly crashed on separate machines after Shell tests with:
The stack ran through
TypeManager.CreateInstance -> AndroidValueManager.CreatePeer -> Fragment.n_OnDestroyView. A preceding CoreCLR run stack-overflowed repeatedly in the sameFragment.n_OnDestroyViewnative callback.Root cause:
ShellItemHandlerAdapter.Dispose()andShellSectionHandlerAdapter.Dispose()called_wrapperFragment?.Dispose()on the managed callable wrapper before AndroidXFragmentManagerhad finished native fragment teardown.FragmentManagerstill owned the fragment and later invokedOnDestroyView/OnDestroy; the managed peer had already been disposed, so the native-to-managed callback failed.Fix: Remove the premature
_wrapperFragment?.Dispose()call in both adapters.Destroyed?.Invoke,DisconnectHandler(), and clearing_wrapperFragmentare preserved, so handler cleanup and event semantics are unchanged. AndroidX completes the fragment lifecycle and releases its native references, after which the managed wrapper can be collected normally.Changes
ShellItemHandlerAdapter.Dispose()no longer disposes its FragmentManager-owned wrapper fragment.ShellSectionHandlerAdapter.Dispose()applies the same ownership correction.Validation
maui-prbuild 1537782 completed successfully.maui-pr-devicetestsbuild 1537785 completed. The overall pipeline is red only for unrelated, baseline/platform-mismatched test failures listed below.285167e7-e91d-48bf-affa-af69928f75e4completed the full Controls suite. Its log contains noStack overflow,Fragment.n_OnDestroyViewcrash, wrapper activation exception, orDEVICE_NOT_FOUND.83a0120e-b322-4681-8d71-152b5fe03b4alikewise completed the full Controls suite with none of the prior crash signatures.setSpan (5001 ... 5001) ends beyond length 5000). The identical Entry failures already occur on the exact-base build1537360, including its Mono Controls work item.StatusBarThemeAppliesWhenHandlerConnectsfailures (MauiContext did not have a valid window), identical to exact-base build1537360on both runtimes.StatusBarThemeFlowsThroughRootControllerfailure is also present on exact-base build1537360; one CoreCLR iOS 26 WebView URL-encoding test also failed.maui-pr-uitestsbuild 1537784 remains in progress. Its completed WinUI failures are unrelated:DragEventsand the Label visual-baseline failures reproduce on exact-base UI build1537359;HorizontalGridFooterExpandsToContentWidthruns on Windows, where these.Android.cschanges are not compiled.11.0.100-preview.7.26379.122SDK or XHarness installed. No local test result is claimed.