This patch eliminates the --preview-dart-2/--no-preview-dart-2 flag,
hardcoding all uses to true. It also defaults all previewDart2 method
parameters to true, where they hadn't yet been.
A series of subsequent patches will eliminate all previewDart2
parameters and the associated code from within the codebase.
//mobile/flutter/tests/app:basic_runner_test_*
during a google3 roll.
The following exception was being thrown
_TypeError: type 'String' is not a subtype of type 'File'
```
8)
<asynchronous suspension>
utter_command.dart:347:18)
<asynchronous suspension>
/flutter_command.dart:282:33)
<asynchronous suspension>
xt.dart:142:29)
<asynchronous suspension>
* Extract some of startApp into a reusable method
* Get basic attach --machine working
* Attach --machine tweaks
Move validation to validate method and create daemon early so we get the startup event before trying to get a connection.
* Bump daemon version so we know whether it's valid to flutter attach
* Tweak output text
* Swap package imports for relative
* Review tweaks (naming, formatting, typedefs)
* Separate arguments from process spawning
This will make calling attach easier
* Add a basic test for flutter attach --machine
* Fix crash if port unforward modifies the list of forwarded ports
* Add a no-op port forwarder for flutter-tester
* Switch to using BasicProject instead of our own inline code
* Fix expectation in test now we have a portForwarder
* Remove stale TODO (this is done)
* Tweak formatting
* Change some Completers to void to fix Dart 2 issues
fuchsia_tester.dart still assumes Dart 1. Previously, it ran tests directly
from source, flutter_platform.dart automatically runs a kernel compile when
operating in Dart 2 mode, but this assumes a functional Dart SDK is available
in the artifacts directly, and fuchsia_tester.dart mocks out the artifacts
directory with an empty temp dir.
Remaining work is:
1. Get the frontend server building as a dependency on Fuchsia.
2. Patch fuchsia_tester.dart to use a valid Dart SDK and frontend server.
This also reverts migration to Dart 2 typedef syntax.
This reverts commit 6c56bb2. (#18362)
This reverts commit 3daebd0. (#18316)
* It's time to #deleteDart1 (#18293)
Eliminates support for Dart 1 in flutter_tools, and drops our Dart 1
benchmarks. All commands now run in Dart 1 mode only.
Eliminates --preview-dart-2 / --no-preview-dart-2 support.
* Fix indentation, remove no longer necessary .toList()
* Only push udpated kernel if >0 invalidated srcs
Eliminates support for Dart 1 in flutter_tools, and drops our Dart 1
benchmarks. All commands now run in Dart 1 mode only.
Eliminates --preview-dart-2 / --no-preview-dart-2 support.
* Add to Artifacts, and add optional arguments to entry points for flut… (#15185)
Add to Artifacts, and add optional arguments to entry points for flutter run and test to allow for wiring up the same with preview-dart-2 internally
* Changing packages uri here is not necessary
By default flutter run will build a 64-bit APK if the attached Android device
is 64-bit. Specifying --target-platform=android-arm will deploy a 32-bit APK
to a 64-bit device.
Fixes https://github.com/flutter/flutter/issues/14526
* Make the current command injected into the AppContext, allowing
other classes to inject the current command.
* Introduce `AssetBundleFactory`, an injected factory class for
spawning instances of `AssetBundle`. This allows other run contexts
to use custom asset bundling logic.
* Clean up RunCommand by removing a 'packages' argument that duplicated
a global argument by the same name (and for the same purpose).
Duplicate arguments are confusing and error-prone.
* Plumb a --strong option through to the front end server and the engine
so that we can run flutter apps in preview-dart-2 and strong mode
* - Address analyzer lint issues
*- correctly set up strong mode option in the case of AOT builds
This CL introduces 2 hidden options to 'flutter build aot' and 'flutter run' for passing arbitrary arguments to front-end server and to gen_snapshot tool when building and running flutter app in --profile or --release modes.
The ability to pass arbitrary options simplifies various experiments, as it removes the need to change defaults and rebuild flutter engine for every tested configuration.
