The BaseInputConnection superclass does not call endBatchEdit
in setSelection and therefore does not implicitly cause
InputConnectionAdaptor to send a state update.
Some input modes such as numeric keypads will not function without
these updates.
This PR touches variable names, class names, and file names so it's significantly more risky than its predecessor https://github.com/flutter/engine/pull/17329
Due to file name changes, this PR is expected to change the license files.
We haven't rename `shell/gpu` to `shell/raster` yet. It should be optional but I think it's better to have `raster_surface_software.cc` than `gpu_surface_software.cc`.
Chrome Trace viewer treats events labeled "VSYNC" as special and highlights them (when the "Highlight Vsync" checkbox is enabled). Ideally VSYNC events are generated by the host system at their source. System VSYNC events are indeed present in full-system systraces. Flutter-level traces (as seen in Observatory/Flutter devtools) do not contain the system VSYNC events, so we rely on the engine to generate them (as close to where they would be generated by the system ideally).
Currently the common (platform-independent code) generates VSYNC events at the time when the UI thread starts processing a frame. This has two drawbacks:
1. The traces are generated with a delay (we wait for the callback to be have been scheduled on the UI thread instead of tracing as soon as the system notified us.
2. When inspecting system-wide traces we'll have both the system and the Flutter app (or potentially multiple Flutter apps) generate VSYNC events at the same time. This confuses both the developers and the trace viewer.
This change moves the VSYNC event generation to the platform-specific embedder implementations:
1. On Android/iOS we always generate the VSYNC event since Android/iOS developers use Flutter tools to debug the apps.
2. On Fuchsia we do not generate VSYNC events since the systraces always contain them.
3. In the Embedder wrapper we don not generate VSYNC events and rely on the actual embedder to do this in a way appropriate for the target system.
* Add support for software text editing controls
Includes selection, copy, cut, paste, as well as partial support for up
and down movement.
Text editing controls can be accessed in GBoard by:
top-left arrow > three dots menu > text editing
Partial fix for flutter/flutter#9419 and flutter/flutter#37371.
* Introduce InputConnectionAdaptor tests
Run with:
testing/run_tests.py --type=java --java-filter=io.flutter.plugin.editing.InputConnectionAdaptorTest
* Fix BUILD.gn comment on run_tests.py --java-filter flag
This shouldn't result in any logical changes. I've done a quick smoke
test by building a local Android engine and running Flutter gallery, no
compile errors or other obvious issues.
Applied by running `/ci/format.sh | patch -p0` with the altered script
added in flutter/engine#16500. I did locally modify the script slightly
further so it would run against all Java files in the repo instead of
just modified ones.
This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.
FlutterView#enableTransparentBackground has been deprecated for some
time now since it breaks a11y highlighting in most cases. When the
warning was first added there was no known workaround, but now the v2
embedding is in stable and ready to support this usecase. Update the
warning to point to the v2 embedding.
Some parts of the embedding (e.g. VsyncWaiter) may hold global references to
system services obtained through the context used during initialization.
These must not be associated with an activity or other non-application context.
Fixes https://github.com/flutter/flutter/issues/49612
Currently we're automatically registering plugins both when the
FlutterEngine is constructed and in the `flutter create` template, when
FlutterActivity#configureFlutterEngine is called. The initial
registration is too early to contain a reference to the activity and the
second registration can cause problems in some plugins.
This alters the flow so automatic registration happens in two discrete
places, and contains the `activity` in its first and only call for most
apps.
1. We're no longer automatically registering plugins on `FlutterEngine`
in any of our activities/fragments at construction time. But since the
FlutterEngine default constructor still automatically registers plugins,
anyone constructing the engine themselves (for example, in a service) is
still going to get automatic registration at `FlutterEngine`
instantiation time.
2. We now automatically register plugins in the base `FlutterActivity`'s
`configureFlutterEngine` hook. Anyone using `FlutterActivity` (or
`FlutterFragment`) should be automatically registered once that hook is
called. Right now the `flutter create` template overrides the base class
method with a subclass that registers everything manually in the same
spot. But with this in place we can safely recommend to remove the
subclass and rely on this hook to automatically register going forward.
Registering at this time means `activity` is set correctly.
Eliminates an unused dependency on android.os.build. The last remaining
use of this was eliminated in 0615f45623224bd99ee3ceb8ba4a0d4d04f58d54
with the removal of an unused method that contained an android version
check.
This changes the InputConnectionAdaptor so that it will execute an IME action when ENTER is pressed. Prior to this, pressing ENTER on a hardware keyboard did nothing.
