- Switch core snapshot to Dart 2 and remove support for loading platform.dill.
- Remove support for loading script snapshots.
- Remove support for loading source.
- Remove settings and fix names to reflect the above.
- Remove support for loading the service isolate from source.
Otherwise the callbacks may be called after FlutterNativeView is destroyed and is null.
Also defensively check for whether the texture is already released in the callback because the callback may be called from another thread by a stale reference (see the comment).
This closes https://github.com/flutter/flutter/issues/20951.
The following were previously marked as deprecated over a month ago:
* `FlutterStandardBigInteger`
* `-[FlutterDartProject initFromDefaultSourceForConfiguration]`
Remove their implementations and mark them as unavailable.
Add a `-[FlutterViewController splashScreenView]` property
Add a `-[FlutterViewController splashScreenView]` property that
clients can use to customize the launch view (issue #17140).
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.
