Tracking issue for non-blocking follow-ups identified during review of #34758 (Android Shell handler-based rewrite). None of these blocked merge; they are latent gaps / compat concerns worth addressing as cleanup.
1. StackNavigationManager.Connect(IView) shipped-API binary break
PR #34758 changed StackNavigationManager.Connect and moved the original 1-arg overload to *REMOVED* in src/Core/src/PublicAPI/net-android/PublicAPI.Shipped.txt:
*REMOVED*virtual Microsoft.Maui.Platform.StackNavigationManager.Connect(Microsoft.Maui.IView! navigationView) -> void
virtual Microsoft.Maui.Platform.StackNavigationManager.Connect(Microsoft.Maui.IView! navigationView, AndroidX.Fragment.App.FragmentContainerView? fragmentContainerView = null) -> void
Because Connect(IView) was a shipped API, the change is source-compatible (default param) but not binary-compatible: precompiled callers that bound to the 1-arg IL signature will hit MissingMethodException at runtime, since the optional parameter is resolved at the call site.
Proposed fix: re-add a thin Connect(IView) overload that delegates to Connect(IView, null), restoring binary compatibility. (Same pattern applies to the FlyoutViewHandler base-type change ViewHandler<IFlyoutView, View> → ViewHandler<IFlyoutView, MauiDrawerLayout>, which should at minimum be release-noted as a breaking change for custom Flyout handler subclasses.)
2. ShellItemWrapperFragment missing OnDestroyView (latent robustness gap)
src/Controls/src/Core/Handlers/Shell/ShellItemWrapperFragment.Android.cs overrides OnCreateView / OnViewCreated / Dispose but has no OnDestroyView. This is not an active bug today: the wrapper fragment is added once via .Replace(...).CommitNow() with no back stack, is not hosted in a ViewPager2, and config-change restoration hits the _handler is null guard (Shell reconnects a fresh instance). So OnCreateView/OnViewCreated run exactly once per handler-bearing instance.
However, it is a latent gap: if the hosting model ever changes to allow the fragment's view to be destroyed and recreated while the handler instance survives, ShellItemHandler.SetupViewPagerAdapter() skips the _viewPager.Adapter = assignment when _adapter is not null, which would leave a blank screen, and the retained views would leak.
Proposed fix: add a defensive OnDestroyView that clears the view references (and resets the adapter assignment path) so the fragment is robust to view recreation.
Filed as a consolidated follow-up after #34758 merged. #1 is the most user-impactful (binary compat); #2 is lower priority cleanup.
Tracking issue for non-blocking follow-ups identified during review of #34758 (Android Shell handler-based rewrite). None of these blocked merge; they are latent gaps / compat concerns worth addressing as cleanup.
1.
StackNavigationManager.Connect(IView)shipped-API binary breakPR #34758 changed
StackNavigationManager.Connectand moved the original 1-arg overload to*REMOVED*insrc/Core/src/PublicAPI/net-android/PublicAPI.Shipped.txt:Because
Connect(IView)was a shipped API, the change is source-compatible (default param) but not binary-compatible: precompiled callers that bound to the 1-arg IL signature will hitMissingMethodExceptionat runtime, since the optional parameter is resolved at the call site.Proposed fix: re-add a thin
Connect(IView)overload that delegates toConnect(IView, null), restoring binary compatibility. (Same pattern applies to theFlyoutViewHandlerbase-type changeViewHandler<IFlyoutView, View>→ViewHandler<IFlyoutView, MauiDrawerLayout>, which should at minimum be release-noted as a breaking change for custom Flyout handler subclasses.)2.
ShellItemWrapperFragmentmissingOnDestroyView(latent robustness gap)src/Controls/src/Core/Handlers/Shell/ShellItemWrapperFragment.Android.csoverridesOnCreateView/OnViewCreated/Disposebut has noOnDestroyView. This is not an active bug today: the wrapper fragment is added once via.Replace(...).CommitNow()with no back stack, is not hosted in aViewPager2, and config-change restoration hits the_handler is nullguard (Shell reconnects a fresh instance). SoOnCreateView/OnViewCreatedrun exactly once per handler-bearing instance.However, it is a latent gap: if the hosting model ever changes to allow the fragment's view to be destroyed and recreated while the handler instance survives,
ShellItemHandler.SetupViewPagerAdapter()skips the_viewPager.Adapter =assignment when_adapter is not null, which would leave a blank screen, and the retained views would leak.Proposed fix: add a defensive
OnDestroyViewthat clears the view references (and resets the adapter assignment path) so the fragment is robust to view recreation.Filed as a consolidated follow-up after #34758 merged. #1 is the most user-impactful (binary compat); #2 is lower priority cleanup.