We were already skipping the check in `flutter upgrade` but this also spawns `flutter precache` and `flutter doctor` which would still check and potentially output the message.
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.
* Send an event at startup with the protocol version and pid
The pid will help with some of the issues of terminate the process when launched through a shell script and the version will allow clients to make decisions about supported features.
I've also bumped the protocol version number for two reasons:
1. This change
2. We didn't increase it when we added the previous emulator commands
When running with --local-engine, build single-architecture apps, rather
than what's declared in the Xcode project.
By default, Flutter creates Xcode projects that generate universal
binaries supporting both armv7 and arm64 processors. Since local engine builds
are all single-architecture, override the Xcode project's ARCHS setting
with the appropriate value for the specific engine.
NOTE: this assumes engine paths consistent with those used in the engine
repo: 32-bit iOS engine builds end in _arm, 64-bit builds do not.
Our style guide says the k's are not necessary, and it seems like a good idea to make all the code be consistent on this.
Only naming changes to private vars: no logic changes.
Further digging revealed that the reason --no-sim-use-hardfp was
required to be specified explicitly was that Android engine gen_snapshot
binaries are built on Windows with target_os=win.
Previously, the only hook into the rasterizer schreenshot code path
was via FlutterDriver.screenshot. This adds the ability for the
Flutter tool to hook into all three types of screenshots:
1. device (e.g. `adb shell screencap`)
2. Skia (capture spk)
3. Rasterizer (capture PNG via the engine)
This reverts #17147, which was safe under the assumption that
getArtifactPath() returns a platform-specific gen_snapshot instance
(which have the correct default set for this flag) -- it turns out that
though we pass the platform to getArtifactPath(), we always return the
host gen_snapshot for Android.
A followup patch will update getArtifactPath and revert this patch.
We've always cached kernel compiles during bundle builds. This adds
caching for kernel compiles during AOT builds by moving caching into the
KernelCompiler.compile() method rather than around each invocation of it.
This also filters buildbot paths included by the kernel compile that are
not present on the local machine at paths /b/build/slave/Linux_Engine/...
The kernel compiler should probably include an option to not emit these
paths in the depfile, since these are used both by Gradle and the
Fingerprinter class.
Previously, Flutter did not support iOS devices with armv7 or armv7s
CPUs. We now support these devices. This eliminates the previous
hardcoded checks that prevented running on simulators of older devices.
We maintain the existing restriction on running on watchOS or tvOS
simulators.
Previously, in non-release (i.e. profile) AOT builds, we were setting
--no-checked and --conditional_directives flags. --no-checked is the
default, and we don't make use of conditional directives in Flutter.
Allows users of Fingerprinter to filter the set of paths collected from
the explicitly-specified paths and those collected from depfiles.
In some cases, depfiles are emitted with files that are not present on
the local disk (e.g. the frontend compiler currently emits buildbot
paths for the dart core libraries and dart:ui). These files will not
materially affect whether we need to re-run a build action for which
they are inputs, since they're not present in the filesystem and
therefore cannot change.
Depending on whether can read the AVD (or it even has all fields populated) we might get extra "empty" columns, so this trims all blank cells from the end.
