(This is a summary of my current understanding; it's possible there are mistakes here.)

Prior to Flutter 3.0, we had two modes for Android PlatformViews:

• Virtual Display: min SDK version 20, lots of limitations around non-trivial views (no a11y support, some secondary controls in webviews didn't work, etc.)
  • This was selected using initAndroidView, which mapped to TextureAndroidViewController.
• Hybrid Composition: min SDK version 19: has threading implications, and performance on Android <10 is poor, but highly compatible.
  • This was selected using initSurfaceAndroidView, which mapped to SurfaceAndroidViewController.

In 3.0 we added a new mode (it doesn't have a formal name, but the initial PR for it refers to "hybrid composition rendered as a texture layer", so I'm going to call it Texture Layer Hybrid Composition for now). The theory was that this would be strictly better than both modes and would thus replace both, and it was landed that way. But since then, various regressions were discovered and changes were made to the flow, most notably the recent flutter/engine#33599

In the new flow, AFAICT, the modes are:

• Texture Layer Hybrid Composition: min SDK version 23, and doesn't work with SurfaceView. Also apparently doesn't handle transparency on SDK <29
  • This is selected using either initSurfaceAndroidView or initAndroidView if the SDK and view type requirements are met.
• Virtual Display: now selected as a fallback for initSurfaceAndroidView or initAndroidView for SDK <23 or for SurfaceView native views.
• Hybrid Composition: now selected with initExpensiveAndroidView.

If this is correct, there are some pretty bad effects from the current state, for plugins that previously used Hybrid Composition. They now either use the new TLHC mode (which was the initial goal, when it was thought that this was a transparent update), or with the most recent change fall back to Virtual Display. So for instance webview_flutter (which we had previous switched to default to HC), which we don't want to be using VD due to the significant limitations, now does in some cases, in which case we unexpectedly:

• dropped support for SDK 19, and
• will have functionality regressions in SDK 20-22

And the only way to fix that would be to fully switch it to HC again (initExpensiveAndroidView), which means we wouldn't get the new behavior mode even when it would be supported.

I don't think this is a good state to leave the transition in. I see two better options:

1. Revert the behavioral change for initSurfaceAndroidView (so it goes back to using HC) and add a new explicit opt-in to the new mode.
2. Keep track of whether initSurfaceAndroidView or initAndroidView was originally called, and restructure things so that the fallback in unsupported cases is either to VD or HC depending on what was originally called, so that existing HC plugins don't have behavioral changes on SDK 20-22.

/cc @bparrishMines @cyanglaz @GaryQian @dnfield @Hixie for thoughts.