Would close/supersede #143471.

Background

Our (current) Android embedding APIs are inverted, we ask our users to create a specific backend texture (i.e. createSurfaceTexture or createImageTexture). This has problems for backwards and forwards compatibility, and means the Flutter engine lacks the ability to migrate our implementations to better techniques without a migration.

We've solved this by introducing a new opaque API, createSurfaceProducer, that picks the appropriate backend for the user. You can read more about that API, and the migration to come at #139702.

The tl;dr is that createSurfaceProducer is now a multi-branched API that either:

1. Creates a SurfaceTexture (API version <= 28)
2. Creates an ImageReader (API version >= 29)

In other words, to be able to answer the question "our Android embedder can render stuff", we need (currently) to be able to run a real device or emulator at Android API version 28, which, for reasons I don't quite yet understand, are very flaky (#143471). I'll also add that due to the complexity of running Android emulator v28 tests locally on an ARM64 Mac, that any progress to significantly improve this situation is likely to be very slow (days -> weeks, not hours -> days).

Proposal

Make FlutterRenderer.debugForceSurfaceProducerGlTextures public and use it in scenario_app.

This would remove the need to configure and debug an Android v28 emulator at the cost of worrying about the use of public @VisibleForTesting APIs (of which we appear to have many already: