It looks like half the code in this function was updated to use the
main bundle but this one line was still only using the _dartBundle. I am
pretty sure that is a mistake and instead we want to use the mainBundle
as a backup both to find the plist and to find the assets.
Started cleaning up the accessibility handler when the bridge is
deleted and made nilling out channels safer by making sure they don't
overwrite newly setup handlers.
UIKit does not guarantee that the application is in the active state when it
lays out it subviews. However, in `viewDidLayoutSubviews`, Flutter attempts to
create the render surface and wait for the first frame. These operations require
GPU access which is forbidden when in the background on iOS. This layout while
in the background only seems to happen under very specific circumstances as
described in the reproducible test case. Notably, this behavior cannot be
reproduced when the application is just launched with the "Background Fetch"
XCode run scheme. The other instance of invocations to create the rendering
surface have been audited and I can confirm that those are already in the
correct lifecycle callbacks. This was the only instance where the surface
creation was in a non-lifecycle callback.
Fixes https://github.com/flutter/flutter/issues/55969
(This issue has a clear reproducible test case and was used as the basis for
verification.)
Fixes https://github.com/flutter/flutter/issues/57676
(This is significantly harder to reproduce but the issue looks to be the same. I
tried this patch on multiple devices overnight and could not reproduce this.)
This underlying cause here was identified by the enhanced GPU error reporting
introduced in iOS 14. I am not able to submit those patches because the Beta
builders are not available on infra. I will submit those when available so that
issues like this have more actionable error messages in the future.
This change makes it so that we track all the motion events encountered by `FlutterView` and all of its subviews in the `MotionEventTracker` class, indexed by a unique `MotionEventId`. This identifier is then passed to the Flutter framework as seen in https://github.com/flutter/flutter/pull/60930. Once the gestures take part in gesture disambiguation and are sent back to the engine, we look-up the original motion event using the `MotionEventId` and dispatch it to the platform.
Bug: https://github.com/flutter/flutter/issues/58837
Additionally create "_next" permutations for all of the test binaries
on Fuchsia, in order to test both code-paths.
Using the #define follow-up CLs can also create a flutter_runner_next
binary that does not contain any legacy integration code.
BUG: 53847
* Add PlatformView support for Fuchsia
This change allows embedding views provided by fuchsia components into
a flutter app running on Fuchsia. This conforms to Flutters idiomatic
approach to composite PlatformView alongside other rendered layers.
This uses the `view embedder` infrastructure to allow
`PlatformViewLayer`
to hold fuchsia views. This is meant to eventually supplant the legacy
`SceneHost` and `ChildViewLayer` mechanism to embed fuchsia `ChildView`.
To see how this will get used check out:
https://fuchsia-review.googlesource.com/c/experiences/+/398536/6/examples/hello_experiences/lib/fuchsia_view.dart
Includes unittests for platform_view.cc.
Note: This change has no impact on the legacy code to embed fuchsia
views.
* Rename OnCreateViewMethodCall to OnCreateView
Same for OnDestroyViewMethodCall to OnDestroyView
Co-authored-by: Sanjay Chouksey <sanjayc@google.com>
