Fixes https://github.com/flutter/flutter/issues/123307 - for Android, iOS, and Web, for the main display only (https://github.com/flutter/flutter/issues/125938 tracks supporting multiple displays, https://github.com/flutter/flutter/issues/125939 for desktop).
Desktop will need to be implemented for this, but given priority for a couple of our customers targetting foldable devices on Android I'm inclined to get this in before desktop can be finished.
The main concern for this right now is that on some Android foldable devices, setting a preferred orientation will cause letterboxing and the `MediaQuery` will _never_ get the full screen size when unfolded. This causes apps to think the screen is smaller than it is, as they've mainly been using `MediaQueryData.size` to figure this out. Android's recommendation is to not set a preferred orientation, and if you must to use the new method introduced in `ViewUtil.java` to calculate the maximal window size.
This introduces `PlatformDispatcher.implicitView`, a low-level primitive for the framework's bootstrapping. Most code, including the framework after bootstrapping, will use `View.of(context)` instead of this new API. This new primitive will let us deprecate the `window` global.
Goals:
1. **Enable multi-window**. The `PlatformDispatcher.implicitView` is nullable. If `null`, the app must create a window to get a view it can draw into.
2. **Backwards compatibility**. For "single window" apps, `PlatformDispatcher.instance.implicitView` should behave as similar to `window` as possible.
1. The `PlatformDispatcher.instance.implicitView.viewId` should be `0`.
1. The `PlatformDispatcher.instance.implicitView` must be available synchronously at root isolate startup. This allows the framework to determine if it can make single window assumptions at startup.
2. The `PlatformDispatcher.instance.implicitView` reference must not change after startup: if it is null at startup, it must always be null; if it is non-null at startup, it must always be non-null. If "single window" app enters headless mode, the implicit view must remain non-null.
In the future, the embedder will control whether an implicit view is created: mobile & legacy desktop apps will have an implicit view, multi-window desktop apps won't have an implicit view. This requires updating the engine's embedder API and is out-of-scope for this change. For now, all apps will have an implicit view.
Part of https://github.com/flutter/flutter/issues/120306
This patch also eliminates some extraneous tracing that is happening
every frame. It is possible to get the same trace calls by enabling
the API stream if needed.
Also refactors the NotifyIdle callsites to just always work in
TimeDeltas rather than converting back and forth between them and
TimePoints, which I think reads more clearly.
* Add calls to Dart_NotifyDestroyed when the flutter view is destroyed.
* Add unit test case.
* Format.
* Ensure the destroy task runs.
* Address code review comments.
This PR changes how embedder API's SendKeyData sends ui.KeyData to the framework. The packets are now sent over the existing platform messenger, reusing the entirety of its code path and functionalities while keeping the embedder API unchanged
Group together externally-managed UIDartState.
It's a frequent pattern to enable access to shell resources from the
framework via UIDartState. These handles are passed through several
other objects, where they lay mostly dormant. This refactor just aims
to ease maintenance of this state.
UIDartState is essentially just an easy to extend bus for dropping
off the shell kids in UIDartState, with constructors/operators that
remove the need for providing a full initializer lists in unittests.
Corrects uses of setup as a verb to 'set up', leaves noun/noun-phrase
forms of setup as 'setup'. Also settles on 'teardown' as opposed to
tear-down for consistency across the codebase.
A few other minor comment/wording corrections.
* Revert "Revert "Set SkPath::setIsVolatile based on whether the path survives at least two frames (#22620)" (#23044)"
This reverts commit feda80cb42f99e2588a9a6b9ab3dd1f812d0f45b.
* Fix tracing
This re-lands #20496 and #21780 after fixing the semantics-enabling code that was causing the post-submit web_smoke_test to fail.
Below is the description from the original PR:
This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window.
The design doc for this change is here.
The major changes in this PR:
Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class.
Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton).
Next step after this PR lands:
Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first.
The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
This regression was introduced in https://github.com/flutter/engine/pull/21820
for sound-null safety. The settings used to launch the VM were incorrectly used
to determine the isolate lifecycle callbacks. Since the first shell/engine in
the process also starts the VM, these objects are usually identical. However,
for subsequent engine shell/engine launches, the callbacks attached to the new
settings object would be ignored. The unit-test harness is also structured in
such a way that each test case tears down the VM before the next. So all
existing tests created a bespoke VM for the test run, and, the tests that did
create multiple isolates did not also test attaching callbacks to the settings
object.
Fixes https://github.com/flutter/engine/pull/22041
