Previously, using Platform.executable (from dart:io) returned null (if
non-null-by-default was disabled) or threw an exception (if NNBD was
enabled) since we weren't setting it.
We now pass the executable name to Dart during VM startup based on the
first value in the FlutterProjectArgs::command_line_argv array passed to
FlutterEngineRun (or FlutterEngineInitialize) on startup. argv[0] (if
specified) is explicitly documented as being required to be the
executable name in embedder.h. In the case where no argv[0] is
specified, we instead set Platform.executable to "Flutter" in order to
avoid violating the (non-nullable) type annotation on
Platform.executable.
Note that dart::bin::SetExecutableName() does NOT make a copy of the
input string, so that value needs to be available for the entire lifetime
of the VM.
This also adds EmbedderConfigBuilder::SetExecutableName() to support
setting a fake executable name in unittests. By default, we continue to
set the name "embedder_unittest" unless overridden using this method.
See: https://api.flutter.dev/flutter/dart-io/Platform/executable.html
See: https://github.com/dart-lang/sdk/issues/48427
Issue: https://github.com/flutter/flutter/issues/83921
WinRT was only ever used by the Windows UWP embedder since the main
Windows embedder supports compatibility with Windows 7 and WinRT
requires a Windows SDK target version of at least 10.0.17134.0 (Windows
10, version 1803).
When, at some point, we drop support for versions of Windows earlier
than Windows 10, we'll almost certainly want to resurrect this and start
using WinRT in the main Windows embedder.
The Windows UWP embedder was removed in:
https://github.com/flutter/engine/pull/33019
Issue: flutter/flutter#102172
* Windows: Add SettingsPlugin to separate sending and watching
* remove OnColorValuesChanged
* remove functions and test to handle brightness change from top-level window message
* add settings plugin test
* add files to licenses
* fix license
* use std::optional
* treat error
* fix comment based on code review
This change implements flow control mechanisms for the Accessibility
Bridge that communicates with the Fuchsia semantics services. This
ensures that Flutter acknowledges the pace in which the semantics
manager is consuming updates and only pushes more when they are ready to
be received.
This change avoids entirely touching on the problem of how to break
flutter semantic messages into batches that can fit in the FIDL
channels. This is left for a future change. All code that is related to
calculating size limits of FIDL messages is the same logic, only
changing location in the file.
Test: AccessibilityBridgeTest.BatchesLargeMessages
Bug: fxbug.dev/97596
Added a "Menu.isPluginAvailable" call to allow the framework to query whether a plugin for creating platform menus is available on the current platform.
This will allow the framework MenuBar.adaptive constructor to determine, based on the availability on the platform of the plugin, whether or not to render platform menus. This replaces the old way, which was just to hard code which platforms support it (i.e. just macOS), but that won't work well if someone adds a plugin that supports a particular platform that isn't macOS.
In ANGLE commit 232e523656fccfacabeb8e5ce0cbc2e6dcc1ec4e, an Open GL
extension API was removed from ANGLE which included several symbols that
are not available until OpenGL ES 3.2. This was removed since it had no
known users, and cut the number of entrypoints ANGLE exports in half,
saving 130kB on Android.
Of the removed symbols, the Windows embedder used two:
* GL_RGBA8, which is not OpenGL ES, but rather OpenGL, and can be
replaced with GL_RGBA which is lenient since it doesn't ask for a
specific size.
* GL_CLAMP_TO_EDGE, which can be replaced with GL_CLAMP_TO_BORDER.
https://open.gl/textures for details.
Issue: https://github.com/flutter/flutter/issues/102117
