Part of https://github.com/flutter/flutter/issues/144640.
I'll be moving the rest of the pipeline-dependent tests and packaging a shader bundle for flutter_tester once Flutter GPU works against Vulkan/swiftshader.
Testing if `skia_gold_client` and pre-submit/post-submit is playing nice by triggering an update.
Generated via:
```sh
dart ./testing/skia_gold_client/tool/generate.dart
```
Related: https://github.com/flutter/flutter/issues/144352.
Allow users to update dependencies. Examples:
* `et fetch` Fetch dependencies
In the future, `et build` will update dependencies if it detects that they have changed.
Also:
* Updates the status in the README
* Adds instructions on how to run tests
* Fixes `et run`'s description
* Makes the `--verbose` flag global
## Description
This makes the GTK dependency only active if unit tests are enabled, so that it won't create an undesired dependency on embedded platforms.
## Related Issues
- Fixes https://github.com/flutter/flutter/issues/144421
Adds a flag, `--prefix-logs-per-run`, that defaults to `true` on CI
envrionments.
If present, instead of writing the file `${LOGS_DIR}/logcat.txt`, we
write `${LOGS_DIR}/{prefix}.logcat.txt`. I don't really like this
solution, but alternatives are using zip files (requires downloading to
view) or waiting on generic log improvements.
Closes https://github.com/flutter/flutter/issues/144402.
This is a prototype of the [PlatformIsolate
API](https://github.com/flutter/flutter/issues/136314).
**UPDATE (Jan 25):** The PR is ready for review. PTAL.
The `PlatformIsolate` creation flow is:
1. `PlatformIsolate.spawn` running on parent isolate
(platform_isolate.dart)
a. Create `isolateReadyPort`
b. `PlatformIsolateNativeApi::Spawn` (platform_isolate.cc)
c. `DartIsolate::CreatePlatformIsolate` (dart_isolate.cc)
d. Isolate created. Entry point invocation task dispatched to platform
thread
e. `PlatformIsolate.spawn` returns a `Future<Isolate>`
2. On the platform thread, `_platformIsolateMain` is invoked in the
platform isolate
a. Create `entryPointPort`
b. Send `Isolate.current` metadata and `entryPointPort` back to the
parent isolate via `isolateReadyPort`
3. Back in the parent isolate, `isolateReadyPort.handler` is invoked
a. Send the user's `entryPoint` and `message` to the platform isolate
via `entryPointPort`
b. Use received isolate metadata to create a new `Isolate` representing
the platform isolate and complete the `Future<Isolate>`
4. In the platform isolate, `entryPointPort.handler` is invoked
a. Run the user's `entryPoint(message)`
The engine shutdown flow is handled by `PlatformIsolateManager`, which
maintains a set of running platform isolates.
Basically, I take blank images of red/blue/green squares, like this:
... and use Image Magick to annotate it with the current git hash:
```sh
$ drt ./testing/skia_gold_client/tool/generate.dart
Writing annotation "8069cb4ca1" on images in testing/skia_gold_client/tool/source_images and saving them in testing/skia_gold_client/tool/e2e_fixtures.
Writing to testing/skia_gold_client/tool/e2e_fixtures/solid_red_square.png
Writing to testing/skia_gold_client/tool/e2e_fixtures/solid_green_square.png
Writing to testing/skia_gold_client/tool/e2e_fixtures/solid_blue_square.png
Done: wrote 3 image.
```
... then, I upload the digests very similar to how we do it in `scenario_app`.
---
The idea here is to have a way for me to know if Skia gold is working the way I/we expect, independent of a more complicated test suite with various race-y or flake-y conditions. We could also augment it with tests of "dimensions" properties.
The `run` command builds both the host and target engines and then invokes `flutter run` so that it runs the app using the custom engine builds.
It is expected that 'et run' be used inside the directory of a flutter application.
Command line flags passed after `--` will be forwarded to `flutter run`.
Some examples:
- `et run` Build the debug variant and runs the app in that mode.
- `et run -- --profile` Build the profile variant and runs the app in that mode.
- `et run -- --release` Build the release variant and runs the app in that mode.
Also:
- Start a local_engine.json builder definition (it is missing a lot)
- Tweak the test fixture.
- Add a new Matcher to litetest.
- Tweaked the build config linter to only care about duplicate build names within the same builder.
This reverts commit 98485b3f82fec45a6a0ac932c3c20285a9a14e02.
Reverted in https://github.com/flutter/engine/pull/51056 because it
caused failures in the framework. No changes, but framework test has
been updated to use an actual robolectric implementation to avoid those
failures.
This should not land until
https://github.com/flutter/flutter/pull/144348 has landed in the
framework.
@gaaclarke @johnmccutchan fyi
Unit tests currently output basic hex dumps of skia objects even though we have ostream operators for many of the common ones. It looks like the operators were created in the wrong namespace (flutter/testing rather than the std namespace). Changing the namespace for the associated `assertions_skia` source files makes them compatible with unit tests that deal with these objects provided that the test files include that header and gn dependency, as verified with the `display_list_unittests` here.
This PR causes `run_test.py` to write `info` and higher logs to
`out/run_tests.log` even when `--quiet` is passed. If `--logs-dir` is
also passed, the logs file is copied to that location after all tests
are run.
These flags are added to one invocation on CI to check the correct
behavior.
Right now, the scenario_app tests that claim to use Impeller are not actually using Impeller. This is for a few reasons:
- The arguments passed via instrumentation do not end up by default on the `Intent` for the `Activity` that is under test.
- The arguments passed via instrumentation were in the wrong order and not getting sent to instrumentation at all.
This patch updates existing tests to use a new `@Rule` that reads the arguments from the instrumentation's argument `Bundle` and injects them into the `Intent` that we actually pass to the `Activity` under test. It also updates the argument order in the script and adds a verification that Impeller prints that it is being used at least once.
Reverts flutter/engine#50993
Initiated by: matanlurey
Reason for reverting: The digests will come back negative, as this change shows bugs in the `ImageTexture` implementation.
Original PR Author: matanlurey
Reviewed By: {jonahwilliams, johnmccutchan}
This change reverts the following previous change:
Original Description:
Part of testing https://github.com/flutter/flutter/issues/139702.
Without this PR, the Impeller + Vulkan Scenario App will draw nothing/potentially crash, because there is no way to draw the (current) `SurfaceTexture`-based textures in Vulkan (and never will be).
This change does the following:
- Skia -> Nothing
- Impeller + OpenGLES -> On newer Android devices, uses `ImageReader` instead
- Impeller + Vulkan -> Always uses `ImageReader`
See also: https://api.flutter.dev/javadoc/io/flutter/view/TextureRegistry.SurfaceProducer.html.
Part of testing https://github.com/flutter/flutter/issues/139702.
Without this PR, the Impeller + Vulkan Scenario App will draw nothing/potentially crash, because there is no way to draw the (current) `SurfaceTexture`-based textures in Vulkan (and never will be).
This change does the following:
- Skia -> Nothing
- Impeller + OpenGLES -> On newer Android devices, uses `ImageReader` instead
- Impeller + Vulkan -> Always uses `ImageReader`
See also: https://api.flutter.dev/javadoc/io/flutter/view/TextureRegistry.SurfaceProducer.html.
This moves the ever-growing amount of options and defaults into it's own
class(es).
The test runner itself has no tests (yet), but this shim will make
writing tests easier. I tried to make no other real changes to how the
runner functions in this PR.
Fixes https://github.com/flutter/flutter/issues/144046
When we use the same FlutterLoader from the injector, the initialization method knows it doesn't have to do as much work - using separate Flutter loaders (in this case for every test that derives from TestActivity, which is basically all of them) causes spurious warning messages to be printed for every test.
