Expose setZOrderMediaOverlay in the new embedding

[kf6gpe]

Requested by customer: dream. Mirror issue for https://b.corp.google.com/issues/142107954. Conversation should occur there.

[chinmaygarde]

I am removing the embedder tag as this is Android related and not using the embedder API.

[matthew-carroll]

@mklim I'm curious if you have any thoughts on the API for this.

The embedding API at the Activity/Fragment/FlutterView level is meant to be generally configurable. However, the z-index only seems relevant for a FlutterSurfaceView, which may or may not be used.

I'm thinking we can expose that configuration at each relevant point and then document that it only applies when a RenderMode.surface is used. This comes with the downside that we have APIs that sometimes don't do anything and also increase the set of things that developers need to read about and consider. Do you have any opinions on the API?

[mklim]

@matthew-carroll I don't think I'm as keyed in on this as you are at this point, but my instinct here would actually be to expose the underlying SurfaceView at some appropriate point for advanced users who really need to call SurfaceView specific APIs like this instead of trying to plumb calls all the way through the Android embedding that are ultimately view specific like this one to whatever view is attached. I get that we don't want to provide a false sense of security that any given view will remain associated with a particular engine, which as I understand it was the main problem with the v1 API exposing the view through some of its getters. But I also think wrapping plain old View APIs at a higher level would also be a mistake because then we'd be forcing clients to learn our wrapper layer in addition to Android, and it would inherently be a little confusing where all the API calls wouldn't work in all cases like you've mentioned, and we'd always be lagging in cases like this where we wouldn't be exposing the full API surface some users may want or need.

So ultimately I'd think of exposing a getView method on FlutterActivityAndFragmentDelegate with some clear warnings that there's no guarantees that the view is going to stay current for any amount of time after the API call. Maybe expose it only through some new callback registration so API users who care are forced to register onAdded/onRemoved listeners and so it's obvious through the API that the view is impermanent? That would match the rest of the flow. Could also give the Flutter view a specific ID and tell users who really want it to go find it within the layout directly, but it would be harder to do this since we don't distribute the engine as an AAR right now and so wouldn't be able to distribute the ID as an XML resource.

[matthew-carroll]

The ability to access the FlutterSurfaceView and configure it is now facilitated via the PR here:
flutter/engine#16552

That engine change will need to roll to the framework before becoming general available on master.

Closing this issue as resolved.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.