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.
Uses the `version` property from the `pubspec.yaml` file to set the corresponding fields in the `local.properties` file respectively in the `Generated.xcconfig` file.
The `--build-name` and `--build-number` options have changed. Now they trump the `version` property from the `pubspec.yaml` file.
If the `version` property is not set and the `--build-name` and `--build-number` options are not provided, the build command will not change the `local.properties` / `Generated.xcconfig` file.
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
Adds a class `PubContext` with a fixed set of allowed values
Make it clear these values should not be changed casually
Fixed one inconsistency already: update_packages vs update_pkgs
Provide more information for verify calls
Eliminate `ctx_` prefix.
* Add support for NDK discovery and add --prefer-shared-library option
We would like to be able to use native tools (e.g. simpleperf, gdb) with
precompiled flutter apps. The native tools work much better with *.so
files instead of the custom formats the Dart VM uses by default.
The reason for using blobs / instruction snapshots is that we do not
want to force flutter users to install the Android NDK.
This CL adds a `--prefer-shared-library` flag to e.g. `flutter build
apk` which will use the NDK compiler (if available) to turn the
precompiled app assembly file to an `*.so` file. If the NDK compiler is
not available it will default to the default behavior.
* Rebase, add test for NDK detection, augment flutter.gradle with @Input for flag
* Use InMemoryFileSystem for test
* Remove unused import
* Address some analyzer warnings
I got tired of drive-by spelling fixes, so I figured I'd just take care of them all at once.
This only corrects errors in the dartdocs, not regular comments, and I skipped any sample code in the dartdocs. It doesn't touch any identifiers in the dartdocs either. No code changes, just comments.
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.
This makes command validation happen as part of `verifyThenRunCommand()`,
using a newly introduced protected method (`validateCommand()`) rather than
a `commandValidator` property (that subclasses were responsible for manually
invoking).
* report run target and if it is an emulator
* don't print debug
* rename parameter, remove unused variable
* fix test
* fix comment
* tweak from review, and fix analyzer error
* send custom parameters for the event, not the session
* fix mock
* use the +1 for usage
