When there are no more platform views, make sure the overlay layer is
hidden. When a platform view is added again, show the overlay. The
show/hide allows us to avoid continually recreating and destroying the
overlay surface + swapchain when a platform view slides in and out of
frame.
To further reduce memory usage, we could do a delayed de-allocation of
the overlay layer (say after 50 frames of no platform view, destroy it).
But I'm leaving this to a follow up.
Developers will need to _conditionally_ use HCPP (or the framework will
need to handle it automatically). This requires the ability to query at
runtime whether HCPP mode is enabled + supported.
Add a message channel to do so, and add the usage of this to the
android_engine_test. Does not yet add any automatic selection.
---------
Co-authored-by: Matan Lurey <matanlurey@users.noreply.github.com>
Another large test suite that has never been running.
The underlying thing I _think_ it wanted tested, which was hybrid
composition, is now tested by `android_engine_test`. I also added a red
square on top of each platform view so that, like
`hybrid_android_views`, we can make sure layering is working as
expected.
Any other ideas? Can also be follow-up PRs?
Use the PlatformViewController2 to register a platform view, allow the
dart side platform view logic to opt into this new platform view. Wires
up an integration test with android_engine_test.
Trying to figure out if flake reports
https://github.com/flutter/flutter/issues/162362 and
https://github.com/flutter/flutter/issues/162363 are related to
https://github.com/flutter/flutter/issues/162310.
I was unable to reproduce locally:
```sh
dart tool/deflake.dart lib/platform_view/hybrid_composition_platform_view_main.dart
```
... so either the Mac Android emulators don't show this behavior, or
perhaps its just the slowness of CI VMs.
Either way, this should try taking a screenshot 2 more times (which has
built-in waits/sleeps), so if the problem persists that means there is a
more critical HC problem (the screen is _always_ drawn black sometimes)
versus a more transient problem (it "takes longer").
A few changes in this PR (could have been split up, but that would take
an extra 4 hours - 2 days in CI time):
- Removed the old `flutter_driver_android_test` shards and references
- Override `AndroidManifest.xml` per backend, forcing that backend to be
used (no fallbacks) or it fails
- Bumps the Android emulator to 35 due to the use of magic strings, I
think
The check for the Impeller backend actually being used is the honor
system right now, as a bug in `flutter drive`
(https://github.com/flutter/flutter/issues/162087) prevents me from
seeing error output, meaning that it's impossible to be sure a
particular Impeller backend is used (or understand why a crash happens),
so I guess I'll work on that next.
Due to https://github.com/flutter/flutter/issues/162088, we were
accidentally running our Vulkan tests as OpenGLES 🤦🏼 .
Towards https://github.com/flutter/flutter/issues/161333.
This adds the initial `.ci.yaml` configuration (marked `bringup: true`),
without changing the existing shard to avoid the problems we ran into
last time when I renamed the shard atomically, as well as piping for
providing context in which the test will run (Vulkan or OpenGLES), which
can't be introspected in the _running_ app.
In a follow-up PR I'll:
- Edit `AndroidManifest.xml` before the suite, setting `ImpellerBackend`
appropriately
- Move the bringup nodes to presubmit
- Delete the existing (legacy) node
The goal here is to have a great standalone `android_engine_test` suite
that [replaces
`scenario_app/android`](https://github.com/flutter/flutter/pull/160992).
No test is _functionally_ changed in this PR, but overview of changes:
- Finished renaming the suite `android_engine_tests` instead of
`flutter_driver_android`
- Added instructions and an environment variable for local generation of
golden-files (`UPDATE_GOLDENS=1`)
- Added explanations of the individual tests, where they live, and how
to run them locally
- Added a hybrid-composition (HC, not TLHC, which is already tested)
test
- Renamed "other_smiley" to "surface_texture_smiley" (and renamed the
original to "surface_producer_smiley")
- Removed unnecessary ".android" suffix (we will not run this on
anything but Android)
- Added a `tool/deflake.dart` to run a test suite 10x (or custom) times
locally to try and determine flakiness
After this PR, I'll add flags to let you control variants and name the
screenshots accordingly, i.e.:
- API v34 or v35
- OpenGLES or Vulkan (will require an `AndroidManifest.xml` edit during
the test instrumentation)
Towards https://github.com/flutter/flutter/issues/161261 (before I add
more tests).
This is a 1:1 move, with massaging of
`run_flutter_driver_android_tests.dart` to be more automated as tests
are added.
/cc @reidbaker
