This script runs the Flutter unit tests. By default, the script assumes you
have compiled a SkyShell in an "engine/src" that's a peer to the "flutter"
directory.
We still have the --http option as a fallback for now. Once we're confident the
--no-http version works, we'll drop the --http support.
Also, create the FLX in a temp directory and then delete the temp directory
when we're done. Finally, pull the Linux artifacts from the cloud storage
bucket that the buildbot is uploading to.
Adds a --private-key option to the build command, which specifies an ECDSA
private key. When this is provided along with a manifest, the manifest is
prepended to the .flx package and signed with the private key. The manifest
also includes a SHA-256 hash of the zipped content portion of the .flx package.
This is used by the Flutter updater package, to verify that updates are
from the right publisher.
The `run_mojo` command doesn't integrate with `FlutterCommand` and doesn't
understand how to download its toolchain components ahead of time. Eventually
we should teach `run_mojo` how to integrate with the `Toolchain` class, but
until then, we can fix the regression by eagerly setting
`ArtifactStore.packageRoot` again.
Fixes https://github.com/domokit/mojo/issues/475
A common use case for members of the Flutter team is to have a dependency
override for the flutter package that points back into the engine src tree.
We can use that override to automatically detect the engine src path, which
makes the command line shorter.
This patch adds a couple print statements to explain why the first run of
`flutter start` takes a while. (We need to download the APK and install it on
the device.)
This patch makes `flutter start` work without a clone of the engine git
repository. Making this work pulled a relatively large refactor of how the
commands interact with application packages and devices. Now commands that want
to interact with application packages or devices inherit from a common base
class that holds stores of those objects as members.
In production, the commands download and connect to devices based on the build
configuration stored on the FlutterCommandRunner. In testing, these fields are
used to mock out the real application package and devices.