This change makes it so that we track all the motion events encountered by `FlutterView` and all of its subviews in the `MotionEventTracker` class, indexed by a unique `MotionEventId`. This identifier is then passed to the Flutter framework as seen in https://github.com/flutter/flutter/pull/60930. Once the gestures take part in gesture disambiguation and are sent back to the engine, we look-up the original motion event using the `MotionEventId` and dispatch it to the platform.
Bug: https://github.com/flutter/flutter/issues/58837
* 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 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.
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.
Samsung's Korean keyboard has a bug where it always attempts to combine
characters based on its internal state, ignoring if and when the cursor
is moved programmatically. EG typing "ㄴㅇ" and then moving the cursor
back to the front of the text and typing "ㄴ" again would result in
"ㄴㅇㄴ", not "ㄴㄴㅇ".
Fully restarting the IMM works around this because it flushes the
keyboard's internal state and stops it from trying to incorrectly
combine characters. However this also has some negative performance
implications, so we only apply the workaround on Samsung devices set
to use Korean input.
This also effectively disables the feature on Samsung keyboards that
allowed users to re-open a composing region for previously typed
characters. See https://github.com/flutter/flutter/issues/29341#issuecomment-531283508.
Fixesflutter/flutter#29341.
Naively embedded platform views on Android were never able to receive
keyboard input, because they were never focusable. So far we've worked
around the limiation by hooking into InputMethodManager and proxying the
InputConnection from a focused window over to the embeded view.
Android Q changed InputMethodManager to be instanced per display instead
of a singleton. Because of this our proxy hook was never being called,
since it was being set up on a different instance of IMM than was being
used in the virtual display.
Update `SingleViewPresentation` to store the IMM from the focused window
and return it whenever there are any calls to `INPUT_METHOD_SERVICE`.
This hooks our proxy back into place for the embedded view in the
virtual display. This restores the functionality of our workaround from
previous versions.
Unfortunately there's still a lot of noisy error logs from IMM here. It
can tell that the IMM has a different displayId than what it's expecting
from the window.
This also updates the unit tests to support SDK=27. SDK 16 doesn't have
DisplayManager, so there were NPEs attempting to instantiate the class
under test.
