Fix AlertDialogs built by platform views

[amirh]

This is ugly and fragile, I wish I had a better solution, I'll try to follow-up with Android on a better solution for future Android versions.

This changes the presentation context to check the stack trace of it's callers and if it's an android.app.AlertDialog that is asking for a window manger, return the window manager for the window that hosts the Flutter View and not our custom window manager.

Why we need to do this

When an AlertDialog is created with the presentation context, prior to this fix it fails with:

W/System.err(18979): java.lang.ClassCastException: $Proxy0 cannot be cast to android.view.WindowManagerImpl
W/System.err(18979):    at android.view.Window.setWindowManager(Window.java:769)
W/System.err(18979):    at android.view.Window.setWindowManager(Window.java:750)
W/System.err(18979):    at android.app.Dialog.<init>(Dialog.java:194)
W/System.err(18979):    at android.app.AlertDialog.<init>(AlertDialog.java:201)
W/System.err(18979):    at android.app.AlertDialog$Builder.create(AlertDialog.java:1088)

The presentation context provides a custom window manager that deals with other edge cases of adding windows. Down the line from AlertDialog creation, the Android Framework tries to cast the window manager to a WindowManagerImpl which is a @hide type that we don't have access to, so as long as we provide our custom window manager this cast is going to fail.

Concretely users ran into this when an html select drop down is opened in a webview, as Android WebVIew implements these as alert dialogs: flutter/flutter#34248

Why we want to do this

AlertDialogs are actually intended to show on top of the entire application (the even overlay a translucent gray on top of everything), even if we could confine them inside the virtual display it wouldn't be the intended behavior (as the overlay will not show on top of the entire screen).

Test

I added an integration test in: flutter/flutter#53980

[cyanglaz]

@amirh When creating the WebView, sometimes the context we used is not an activity context.
In the documentation from https://developer.android.com/reference/android/webkit/WebView#WebView(android.content.Context)
It asks the context to be the activity context.
Can't we fix it by making sure to use the activity context when creating the WebView? For example, use ActivityAware apis.

[willvlad]

Is this patch on stable or beta channels now? Flutter_webview is crashing our app whenever there is a dropdown in the webview. Need it fixed urgently!

[VladyslavBondarenko]

@willvlad currently it is already in beta, but not yet in stable