Each platform view created (by a plugin supplied factory) is attached to
a virtual display.
The virtual displays are controlled by VirtualDisplayController objects.
The PlatformViewsController maintains a mapping from a platform view's
id to its VirtualDisplayController, which allows it to operate on the
virtual display for a given platform view ID when asked so over the
method channel.
This is using API level 20 APIs, on lower API levels all platform views
method channel calls are noops.
We can make this work on API 19 with some refactoring to the
TextureRegistry (allow the engine Java code to recycle a texture entry
id).
This CL also adds a platform view id parameter to the
PlatformViewFactory#create() method. This allows plugins to route
platform channel messages to specific instances of a platform view.
TBD in future CLs:
* Forward touch events to the platform views.
* Support accessibility for platform views.
flutter/flutter#19030
To keep the scope of this CL as small of possible I'm leaving the actual
implementation of the platform view mechanics to a following CL.
This CL introduces:
* A PlatformViewsController class which will be responsible for creating,
resizing, and disposing platform views.
* A PlatformViewRegistry which is exposed through the PluginRegistry
and allows plugins to register factories for platform views.
Android plugin code will add support for a new platform view type by
implementing PlatformViewFactory, and registering a factory with the
registry, e.g:
```java
registrar.platformViewRegistry().registerViewFactory(
'webview',
new FlutterWebViewFactory()
);
```
On the Dart side, the framework will ask the engine to create new
platform views by sending a create message over the platformviews method
channel with the unique platform view type id, dimensions, and a unique
id allocated by the framework for the new platform view instance.
The platformviews method channel is also used for resizing and disposing
platform views.
Previously the engine would load all embedded fonts listed in the app's
font manifest during startup. This change creates a Skia font manager that
is backed by the engine's AssetManager and can load embedded font assets
on demand.
* Reland "Added IsolateNameServer functionality (#5410)"
This reverts commit 1598c7ad7b830b298647c17a0c85f3648f6b737d.
* Fixed issue with isolate_name_server_test which caused test to timeout
* Disabled thread_annotations on Android as they aren't supported in the
NDK headers for std::mutex. Readded thread annotations to
IsolateNameServer.
* Added IsolateNameServer functionality, which allows for the association
of string names with isolate SendPort ids that can be used to establish
inter-isolate communications.
Eliminates support for running directly from sources or script snapshots. In
debug mode, we run from a kernel snapshot; in profile and release modes, we
link in AOT-compiled code.
Renames --dart-non-checked-mode to --disable-dart-asserts since checked mode
does not make sense in Dart 2.
* Enforce clang-format on all files in commit
This re-enforces clang-format across all files changed in the commit.
In c10c417, we enabled checking only for the lines changed in the diff
in order to reduce the change of merge conflicts with the shell refactor
landed in 82c5c8f.
* Reformat sources to match latest clang-format
As part of re-enabling clang-format across the codebase, reformat all
code to match the latest toolchain.
* Move the handling of delegating AppDelegate callback out of FlutterAppDelegate.
Also moves the plugin registry to FlutterViewController. So each view-controller will handle its
own plugins.
This is intended to simplify including one or more Flutter views in an existing iOS app and giving
more precise control of plugin registration.
Fixes: https://github.com/flutter/flutter/issues/16539
* formatting
* Update license golden file
* Fixed type error
* FREEZE.unindexed
* Fix Header types
* Revert "FREEZE.unindexed"
This reverts commit bebb70056c9bcb90b4321bdc2873896623ed6faa.
Adds --dynamic and --interpreter flags to
tools/gn. These flags result in engines with
properties as follows:
--dynamic:
- JIT targeting native code on Android and
DBC on iOS
--interpreter
- Target DBC even if running on Android.
For example:
gn --android --dynamic --interpreter --runtime-mode release
Will generate an engine:
- Without Dart asserts
- Without Observatory
- With JIT compililation to DBC
into out/android_dynamic_release_dbc
Eliminates the declaration that only arm64 is supported in
Flutter.framework's Info.plist. This causes Xcode's app thinning tools
to remove Flutter.framework in thinned archives for armv7 devices.
