Skip to content

[Android] Shell: Fix fragment teardown crash - #37048

Merged
PureWeen merged 1 commit into
release/11.0.1xx-preview7from
pureween-didactic-chainsaw
Aug 3, 2026
Merged

[Android] Shell: Fix fragment teardown crash#37048
PureWeen merged 1 commit into
release/11.0.1xx-preview7from
pureween-didactic-chainsaw

Conversation

@PureWeen

@PureWeen PureWeen commented Aug 3, 2026

Copy link
Copy Markdown
Member

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:

System.NotSupportedException: Unable to activate instance of type Microsoft.Maui.Controls.Handlers.ShellItemWrapperFragment from native handle

The stack ran through TypeManager.CreateInstance -> AndroidValueManager.CreatePeer -> Fragment.n_OnDestroyView. A preceding CoreCLR run stack-overflowed repeatedly in the same Fragment.n_OnDestroyView native callback.

Root cause: ShellItemHandlerAdapter.Dispose() and ShellSectionHandlerAdapter.Dispose() called _wrapperFragment?.Dispose() on the managed callable wrapper before AndroidX FragmentManager had finished native fragment teardown. FragmentManager still owned the fragment and later invoked OnDestroyView/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 _wrapperFragment are 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.
  • Both sites document why native lifecycle completion must precede managed peer release.

Validation

  • maui-pr build 1537782 completed successfully.
  • maui-pr-devicetests build 1537785 completed. The overall pipeline is red only for unrelated, baseline/platform-mismatched test failures listed below.
  • Android CoreCLR Controls: Helix job 285167e7-e91d-48bf-affa-af69928f75e4 completed the full Controls suite. Its log contains no Stack overflow, Fragment.n_OnDestroyView crash, wrapper activation exception, or DEVICE_NOT_FOUND.
  • Android Mono Controls: Helix job 83a0120e-b322-4681-8d71-152b5fe03b4a likewise completed the full Controls suite with none of the prior crash signatures.
  • Both Android runtimes reported the same two unrelated Entry failures (setSpan (5001 ... 5001) ends beyond length 5000). The identical Entry failures already occur on the exact-base build 1537360, including its Mono Controls work item.
  • Both Android Core work items reported the two existing StatusBarThemeAppliesWhenHandlerConnects failures (MauiContext did not have a valid window), identical to exact-base build 1537360 on both runtimes.
  • The iOS Helix failures are unrelated to this Android-only diff: the existing StatusBarThemeFlowsThroughRootController failure is also present on exact-base build 1537360; one CoreCLR iOS 26 WebView URL-encoding test also failed.
  • The separately-triggered maui-pr-uitests build 1537784 remains in progress. Its completed WinUI failures are unrelated: DragEvents and the Label visual-baseline failures reproduce on exact-base UI build 1537359; HorizontalGridFooterExpandsToContentWidth runs on Windows, where these .Android.cs changes are not compiled.
  • A MAUI-specific lifecycle review found no high-confidence ownership, teardown-ordering, or leak issue. Retention lasts only until FragmentManager finishes teardown.
  • Focused local Android execution was blocked because this machine does not have the repository-required 11.0.100-preview.7.26379.122 SDK or XHarness installed. No local test result is claimed.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 923e744a-f52b-46ce-939e-b6d27d4f5287
Copilot AI review requested due to automatic review settings August 3, 2026 17:39
@PureWeen
PureWeen temporarily deployed to copilot-pat-pool August 3, 2026 17:39 — with GitHub Actions Inactive
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

@github-actions

github-actions Bot commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 37048

Or

  • Run remotely in PowerShell:
iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 37048"

@PureWeen

PureWeen commented Aug 3, 2026

Copy link
Copy Markdown
Member Author

/azp run maui-pr-devicetests

@PureWeen
PureWeen temporarily deployed to copilot-pat-pool August 3, 2026 17:40 — with GitHub Actions Inactive
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 1 pipeline(s).

@PureWeen

PureWeen commented Aug 3, 2026

Copy link
Copy Markdown
Member Author

/azp run maui-pr-uitests, maui-pr-devicetests

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 2 pipeline(s).

@PureWeen
PureWeen temporarily deployed to copilot-pat-pool August 3, 2026 17:41 — with GitHub Actions Inactive

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 _wrapperFragment in ShellItemHandlerAdapter.Dispose(), relying on FragmentManager to dispose the fragment at the correct lifecycle point.
  • Stop explicitly disposing _wrapperFragment in ShellSectionHandlerAdapter.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

@kubaflo

kubaflo commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

@PureWeen I checked the targeted Android Helix results. The original ShellItemWrapperFragment.OnDestroyView / JNI activation crash is gone in both CoreCLR and Mono runs, so this PR fixed the failure it targeted. The remaining Android failures are unrelated: the two long-Entry setSpan tests in Controls and two status-bar tests in Core.

@PureWeen PureWeen changed the title Fix Android Shell fragment teardown crash [Android] Shell: Fix fragment teardown crash Aug 3, 2026
@kubaflo

kubaflo commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

@PureWeen The intended Shell teardown crash is confirmed fixed at f8b46236 in both Android Mono and CoreCLR Helix runs. The remaining failures are separate regressions covered by #37051 and #37052. Please merge #37048 when the required checks/review allow it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants