This re-lands the key event synthesis implementation for Android (Original PR: #19024, Revert PR: #19956). The only difference is sending the synthesized key events to the root view instead of the current view.
Without sending it to the root view, the system doesn't have any chance of handling keys like the back button. The event will still not be sent to the framework twice, since we turn off event propagation while re-dispatching the event.
AccessibilityBridge installs various listeners for Android events
that invoke Flutter engine APIs. These listeners are removed in
AccessibilityBridge.release. However, in some environments there may
be deferred calls to the listener that will still execute even after
the listener has been removed. This change sets a flag during release
and ignores any listener invocations that happen after the flag is set.
See https://github.com/flutter/flutter/issues/63555 and
https://github.com/flutter/engine/pull/17311
This is a Fuchsia-only shell test, confirming that when the timezone
setting is changed on the realm via Fuchsia's FIDL interface
`fuchsia.settings.Intl`, the Dart isolate running in that realm receives
the change and starts reporting the appropriate timestamp.
We already have a [similar test][tst] that verifies the timezones in the
dart VM matches the local timezone at start, but there was no test that
also verified timezone changes.
[tst]: https://github.com/flutter/engine/blob/master/shell/common/shell_unittests.cc#L1166
See issue #61284
The data race: gl_surface_fbo_frame_infos_ in the test context to was appended
to on the raster task runner but read on the platform task runner. This is now
sidestepped by using a callback and pushing that responsibility to the test.
Setting the callback is guarded behind a mutex.
The race condition: The assertions were previously run when the UI thread was
done generating the frames. However, the assertions were run on the results
collected on the raster thread in response the frame requests from UI thread.
Just run the assertions on the raster thread directly.
Fixes https://github.com/flutter/flutter/issues/64344
* Add native stacktrace on iOS
* Add native stacktrace on Android
* format and changing naming to errorWithCode on iOS
* reformat
* Remove stacktrace from decodeEnvelope, not needed.
* Separate encodeErrorEnvelopeWithStacktrace with original encode function
* Add unit tests
* re-format
* change comments for stacktrace
* Remove changes for iOS
Co-authored-by: Ben Li <libe@google.com>
The Windows embedding was based on the GLFW embedding, which grew
organically from a singe-file implementation that used structs to manage
all of the important state. It is in the process of being converted to a
cleaner object-based architecture, but currently it is a hybrid of
objects and structs that have redundant data, making it very prone to
errors of forgetting to update pointers in multiple locations.
This reduces the remaining structs to only a single pointer to the
larger object that manages the responsibilities that handle is
associated with, so that there is no need to wire things together in
multiple places.
For now they continue to exist as projections of the larger objects, but
that will be eliminated over time by having an object structure that
better reflects the API structure.
Fixes https://github.com/flutter/flutter/issues/64250
The response APIs for method channels and event channels used pointers
for optional parameters; this kept the API surface simple, but meant
that they couldn't take rvalues. As a result, returning success values
or error details often took an extra line, declaring a variable for the
result just to have something to pass the address of.
This converts them to using references, with function overloading to
allow for optional parameters, so that values can be inlined.
For now the pointer versions are still present, so that conversion can
be done before it becomes a breaking change; they will be removed soon.
Part of https://github.com/flutter/flutter/issues/63975
Adds APIs for runners to delegate WindowProc handlers into the Flutter
engine, and for plugins to register as possible delegates.
This allows for plugins to alter top-level window behavior in ways that
can only be done from the WindowProc, such as resize control. This
functionality remains entirely on the native side, so is synchronous.
Part of https://github.com/flutter/flutter/issues/53168
