Issue #1988 results from run-as not working on some phones,
because of Android issue 58373.
This change removes the need for run-as for running
"flutter start". It is still needed for tracing.
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.
When the engine dies unexpectedly during test execution, we have to
terminate any tests running in that engine. Previously, they would just
hang. For some reason that I was never able to satisfactorily explain,
the WebSocket doesn't die in a way I can detect in this case. So
instead, we hand in a future that we only complete when we detect the
server subprocess ends.
Instead of just waiting for the sky server process to start
before we start the activity on the device, this causes us to
wait for the sky server to actually start listening on its port
Fixes#141
Windows has no direct way to kill a process based on port. Uses netstats and loops through the results to find the correct process to kill.
Also modify Process.run for the server to runInShell if on Windows.
Style nits.
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.
Expose the main entry point for the tools via the library lets us run the tools
from the Flutter package, which simplifies the setup for end developers because
they don't need to declare a dependency on sky_tools directly.
In 0.0.15, additional cmdline arguments were not dropped, but now in 0.0.16, the arguments are no longer forwarded.
This patchset would restore this forwarding functionality.
For example, the following command is intended to pass `enable-multiprocess` to the mojo_shell.
`enable-multiprocess` in 0.0.16 does not get passed along, but this patchset would allow it to once again.
pub run sky_tools -v --very-verbose run_mojo \
--mojo-path $MOJO_DIR/src \
--app app.flx --android \
-- \
--enable-multiprocess
This makes the 'package-root' option universal for sky_tools and configures the
ArtifactStore with it statically at startup. The actual sky_engine revision
is computed on demand.
sky_viewer.mojo no longer needs a window manager embedding as of
sky_engine 0.0.27, so this updates the sky_tools run_mojo command so it works
again. This really should be expressed in the pubspec dependencies to avoid
broken combinations but that needs to happen on the sky side.
This adds the following commands to sky_tools:
sky_tools cache clear: Nukes all local artifacts in the cache
sky_tools cache populate: Populates the cache with all known artifacts
This is useful both to fix busted caches and to make sure that the cache is
fully populated so that subsequent operations can proceed without needing
network access.
This teaches commands that need binary artifacts to explicitly instantiate an
instance of the ArtifactStore with the appropriate packageRoot string. The
ArtifactStore can then remember the package root and compute the engine
revision when created and remember those for subsequence calls.
This teaches sky_tools mojo_run --android to invoke mojo's devtool's mojo_run
script with the right flags for invoking sky_viewer on android. This tells the
devtools script to load sky_viewer.mojo from https://storage.googleapis.com/...
and to load app.flx (or whatever the developer specifies as --app) from the
filesystem using the devtools http server.
This initial version assumes the developer has mojo_shell and all other services
sitting on disk somewhere and that they're on linux and only want to run on
linux. This can be generalized down the line to support more use cases. This
downloads the sky_viewer.mojo corresponding to the packages/sky_engine/REVISION
in the developer's directory, so they can specify whatever revision they want.
sky_tools run_mojo downloads sky_viewer.mojo into its cache directory if it is
not present and constructs a command line to pass to mojo_shell that maps the
shebang stamped into the flx to the downloaded sky_viewer.mojo.
Since sky_viewer.mojo lives in the cloud and mojo_shell can load from the cloud
this could also map to an https URL. This should likely be an option.
This adds logic to download and use the sky_snapshot binary from
Google cloud storage when running the 'sky_tools build' command.
The downloaded binary is put into lib/cache/... The binary is
chosen to match the REVISION in the sky_engine package in the
packages directory of whichever package the user wishes to
build a flx from.
Known issues:
*) Assumes linux-x64 host
*) Assumes download will always produce valid executable
*) No clearing of stale cache entries
skyx files are zips, so they can have anything at the start. Having
a shebang line at the start makes it easier to run skyx files in a mojo
environment.
This command will produce an flx package. Currently, this command doesn't work
because we don't have the Flutter compiler downloaded from Google storage yet.
A future patch will make that happen.
This command uses package:test to run Dart tests with sky_shell. For this to
work, we need https://github.com/dart-lang/test/tree/hacky-loader-hook to land.
We're also not smart enough to find sky_shell ourselves yet. Instead, we take
the path as input using an environment variable. Eventually, we'll be able to
get the sky_shell executable from package:sky_engine, but we don't yet ship
that executable.
