The engine was using a global to store a timestamp representing the
launch of the engine. This timestamp is initialized with a JNI call
on Android and during shell setup on other platforms. Later the
timestamp is added to a FlutterEngineMainEnter timeline event used to
measure engine startup time in benchmarks.
This PR removes the global and the JNI call and moves the timestamp
into the settings object.
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.
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.
Adds repeatCount field to KeyEventChannel.FlutterKeyEvent. We set it
to the value returned by KeyEvent.getRepeatCount() and add it to the
message passed through the channel with the intention of exposing it
in RawKeyEventDataAndroid on the framework side.
flutter/flutter#42855
This Pull Request simple adds the deviceId property to the encoding method, I am preparing a next PR on the flutter repository that reads this info and add a property to RawKeyEventDataAndroid on the Flutter side.
This is necessary so we can support multiple gamepads on Android, in order to be possible to make a local multiplayer game with Flutter.
