3a83e43ede
Almost all of the code is just adopting to changes to the APIs of `package:native_assets_builder`, `package:native_assets_cli` and `package:native_toolchain_c` There's only two semantic changes * Removes a test that checks for a verification error if a build hook produces a static library if the preferred linking mode is dynamic: => The test is written in a very hacky way. By monkey patching the build config.json that flutter build actually made. This monkey patching relies on package:cli_config which is now no longer used. => The actual code that checks for this mismatch lives in dart-lang/native repository and is tested there. So there's really no need to duplicate that. * The `package:native_assets_builder` no longer knows about code assets. This is something a user of that package (e.g. flutter tools) adds. Now the dry-run functionality will invoke build hooks who produce code assets without an architecture. => The `package:native_assets_builder` used to expand such a code asset to N different code assets (one for each supported architecture) => This logic was now moved to flutter tools. => In the near future we're going to this dry-run complexity, which will then also get rid of this uglyness (of expanding to all archs of an OS).
Automated Flutter integration test suites
Each suite consists of either a complete Flutter app and a flutter_driver
specification that drives tests from the UI, or a native app that is meant to
integrate with Flutter for testing.
Intended for use with devicelab tests.
If you want to run a driver test locally, to debug a problem with a test, you can use this command from the appropriate subdirectory:
flutter drive -t <test> --driver <driver>
For example:
flutter drive -t lib/keyboard_resize.dart --driver test_driver/keyboard_resize_test.dart