Add VirtualDisplay option for AndroidView.

[XuanTung95]

Is there an existing issue for this?

• I have searched the existing issues
• I have read the guide to filing a bug

Use case

• I want to create a plugin that uses VirtualDisplay mode as default to show my platform view.
• Currently, Flutter doesn't have the option to use this mode. VirtualDisplay is a fallback mode when HCTL is not available.
• I want more control over my plugin behavior by choosing the mode.

Proposal

• Add options to prefer using Virtual Display over other modes

[stuartmorgan]

What's the use case here? The only reason VD still exists is for very specific edge cases; if there's another compelling reason to use it we need to know what that is.

[XuanTung95]

@stuartmorgan

I don't know all the cases but I can imagine some cases related to bugs/limitations of HCTL like:

• SurfaceView is created during runtime.
• Bug related to TextureView
• HCTL has bug with native magnifier

VD mode uses other approaches so It has different pros and cons, if plugins do not meet its bugs, why don't let them use it.

[stuartmorgan]

I don't know all the cases but I can imagine some cases related to bugs/limitations of HCTL

I am not asking for all cases or imaginary cases, I'm asking for your specific motivating case so that we can evaluate if this is the best option for addressing it.

like:

• SurfaceView is created during runtime.

That's tracked in #109690; we're still evaluating whether we can detect that dynamically. (There's also a simple workaround in the meantime.)

• Bug related to TextureView

This is very vague; are you referring to #103686 ? Similarly, that's still being investigated. If it's not solvable, the right approach would be to automatically opt TextureView out the way we do SurfaceView, not to add a new option to force developers to manage that themselves.

• HCTL has bug with native magnifier

Could you provide a link for this please?

VD mode uses other approaches so It has different pros and cons, if plugins do not meet its bugs, why don't let them use it.

As we've explained several times in your other issues and design document about platform views: permanently maintaining lots of modes, and having a complex API surface that makes plugin developers choose between a confusing array of options, are anti-goals for the Flutter team. Our goal is to, as much as possible, simplify the platform view system.

[XuanTung95]

#112712

If you are done with the asking let's talk about why you don't think this is not necessary.

[stuartmorgan]

#112712

Are you saying that bug doesn't affect VD? That seems surprising; if you've actually tested that and determined that it's not an issue for VD, please add that information to #112712. (If not, it wouldn't be a reason to select VD over TLHC.)

[stuartmorgan]

let's talk about why you don't think this is not necessary.

I have explained why our default position is to not add it; the onus is on the proposal to justify that there is a compelling need that makes it necessary to add despite that. The three issues above are not currently sufficient justification, for the reasons I outlined above.

[XuanTung95]

I'm not looking to solve any issue that you asked me to provide.

permanently maintaining lots of modes

Are 3 modes a lot?

and having a complex API surface that makes plugin developers choose between a confusing array of options

Spending a few minutes to read the doc of a param won't hurt. The point is what it does, If dev can make use of it, it has a purpose. Chart libraries have hundreds of options, why dev doesn't complain to reduce the options?

Our goal is to, as much as possible, simplify the platform view system.

I don't think all dev is that lazy and needs your goal

Anyway, I've explained my proposal. About the use case, let's just say I cannot provide a convincing one but thousands of plugins out there may use this option for their own purpose.
If you don't think my proposal is necessary, please close it.

[johnmccutchan]

Hi @XuanTung95 thanks for your request. Our goals for Android Platform Views is to reduce the API surface area but only when we can guarantee good behaviour of any android.view.View hierarchy. We would like to automatically switch to VirtualDisplay mode when necessary (by observing the view hierarchy changes) so that application authors don't need to worry about it.

[johnmccutchan]

FYI- I hope to have an update on this issue sometime in September.

[CarGuo]

In my opinion I would prefer to have a unified API and rendering logic, as the current issue is that different versions of the Flutter SDK may use different behaviors for the same API.

Since we cannot achieve unified rendering logic, it would be better to open it to developers for configuration. Currently, it is neither unified nor controllable, and it is difficult to expect results.

[johnmccutchan]

@CarGuo I am not convinced that we can't achieve a unified API and I hope to deliver one this year.

If we cannot achieve it or the amount of work required to achieve it is too high, I agree we should give more explicit controls to developers so they can decide between the implementations.

[flutter-triage-bot]

This issue is assigned to @johnmccutchan but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!

[flutter-triage-bot]

This issue was assigned to @johnmccutchan but has had no status updates in a long time. To remove any ambiguity about whether the issue is being worked on, the assignee was removed.

[reidbaker]

@johnmccutchan can this be closed now?

[johnmccutchan]

Current status:

• VirtualDisplay is only needed when/if a platform view has a SurfaceView embedded in it.
• VirtualDisplay has low performance and breaks input/a11y handling.
• Capturing VirtualDisplay output into a texture has been flagged as a security/privacy issue by the Android team and we will no longer be able to use this mechanism in the future.

Letting users explicitly pick a mode is problematic, if we had an API that said "Use VirtualDisplay" apps would break on newer versions of Android.

Closing this issue as we need to investigate an alternative to VirtualDisplay mode entirely.

[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.