The default WindowManager implementation in Android's Presentation is
delegating addView/removeView/updateViewLayout calls to the global
WindowManager.
This can result in a crash when an embedded view is trying to e.g show a
PopupWindow.
This change adds a custom WindowManager that overrides
addView (and removeView/updateViewLayout) and adds the view to the
presentation's view tree.
Note that views might keep a reference to the window manager which
might be an issue when we move a view from one virtual display to
another (due to a resize). For this reason when re-sizing we are not
creating a new window manager for the new presentation, but updating the
window manager's references to be relevant for the new presentation and
re-use it.
If `FlutterDartProject` found an `FLTLibraryPath` entry in an iOS
application's `Info.plist`, it assumed that values that were valid
filesystem paths were paths to bundles. If the attempt to retrieve
the `NSBundle` fails, `FlutterDartProject` ignored the failure and
then would assign `nil` to a C++ `std::string`, resulting in a null
pointer dereference.
Add some failure checks to prevent this.
We'd like the ability to add Flutter to existing iOS applications
without requiring that they set `FLTLibraryPath` and `FLTAssetsPath`
in the main bundle's `Info.plist`.
1. Modify `-[FlutterDartProject initWithPrecompiledDartBundle:]` to
support setting the library and assets path from the specified
`NSBundle` instead.
2. If no `NSBundle` is explicitly specified, look for one with a
default bundle identifier ("io.flutter.flutter.app") before
falling back to the main NSBundle.
Also remove `+[FlutterDartProject pathForFlutterAssetsFromBundle:]`
because we don't use it internally, and it isn't exposed in the
header file.
This allows the framework to know that a frame with the resized view is
ready and to behave deterministically to workaround the jank issue
described in flutter/flutter/19572
* Flush all embedded Android view on hot restart.
Adds an OnEngineRestarted method to PlatformView, this is currently only
implemented for Android where we need to use it for embedded views.
* review comments followup
* rename to OnPreEngineRestart, call before Clone
Instead, send them with the new unknown PointerDeviceKind.
We hit this when running `adb shell input tap` in tests which sends events with
an unknown tool type.
This also fills in a missing conversion for TOOL_TYPE_ERASER.
* Add an explicit `-[FlutterViewController init]` implementation
`-[FlutterViewController init]` currently works because it inherits
the `-[UIViewController init]` convenience initializer that invokes
the `-[UIViewController initWithNibName:bundle:]` designated
initializer that `FlutterViewController` overrides.
However, this doesn't seem to be explicitly documented, so it's a bit
confusing (or at least non-obvious), and it seems potentially
brittle. Add an explicit implementation of `-[FlutterViewController
init]` instead.
* Deprecate -[FlutterDartProject initFromDefaultSourceForConfiguration] (#18886)
`-[FlutterDartProject initFromDefaultSourceForConfiguration]` no
longer seems very useful. It calls `-initWithPrecompiledDartBundle:`
or `-initWithFlutterAssets:dartMain:packages:`, but since it now
passes `nil` for all arguments, both paths end up doing the same
thing.
Additionally, `-initFromDefaultSourceForConfiguration` is awkward to
use in Swift. The automatically generated Swift interface is:
public convenience init!(fromDefaultSourceForConfiguration: ())
and it's not obvious how to call that.
Let's deprecate `-initFromDefaultSourceForConfiguration` and instead
expect callers to use the existing `-init` method. (We can make
`-init` do different things for different build configurations later
if necessary.)
Bonus: Rename some parameters to make it more obvious when they may
be `nil`.
Since frontend_server --incremental doesn't support --link-platform, instead of baking host app into the snapshot, load it from kernel file when running in debug mode.
When the FlutterView's window loses focus Flutter cannot bring up the
keyboard (so e.g tapping on text fields doesn't work).
This workaround makes sure that Flutter text fields are working but
unfortunately now the embedded Android view cannot bring up the keyboard
as it's window is not focused.
Submitting this until as a stop gap while we're trying to figure out if
it's possible to allow both windows to bring up the keyboard.
