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.
* Improve variable naming and javadoc for setSystemGestureExclusionRects
* Remove variables from setSystemGestureExclusionRects tests
* Split test for two behaviors into two separate tests for setSystemGestureExclusionRects success case
