In flutter/engine#35233 I unified the platform view creation flow for the different Android platform view modes, since fallback requires inspecting the returned view hierarchy before deciding on a mode. The only difference prior to that change was that HC passed the actual Context, whereas VD and TLHC wrapped the context in a MutableContextWrapper and passed that, since VD mode requires modifying the context later.

I expected this to be a no-op, since it should just proxy everything to the initial context. In practice, this isn't the case; it caused b/249389618, which is a case of HC showing a platform view sometimes in cases when it shouldn't actually be on screen. The non-internal repro steps for that bug are:

• Create the app from the setup steps in Thread assertion failure in SnapshotDisplayList with AndroidPlatformView #113437
  • (Note that this apparently doesn't happen with the Maps new renderer, so also add code like this to ensuring using the LEGACY renderer.)
• Run it
• Press the FAB in the upper left
• Turn the screen off
• Turn the screen back on
• Press the FAB in the upper left

With the MutableContextWrapper, the map is covering most of the resulting screen even though it's no longer part of the widget hierarchy. Without it, the screen is (correctly) mostly empty.

As a short-term fix for the regression, I'm going to stop wrapping the context when HC mode is explicitly requested, since that restores the pre-flutter/engine#35233 behavior for the HC codepath. That's not the right long-term fix though:

• Whatever is happening here would still presumably affect TLHC->HC fallback.
• There seems to be a deeper problem here anyway. [Android]The Hybrid composition Platform view will show on the top of page while resume the app from background. #89558 describes a similar issue with HC + SurfaceView + phone state change causing unexpected view overlays, and that long predates my PR. [android] PlatformView renders on top of everything after orientation change #112929 has a different repro case, but is also similar, and doesn't seem to be related to my change in local testing. This suggests that the problem isn't using MutableContextWrapper itself, but that using it tickles some existing, underlying problem with how we manage the platform view (probably specific to SurfaceView; Android's SurfaceView works by hole-punching, so it can have surprising interactions with other views).