`adb` can sometimes hang, which will in turn hang the Dart isolate if
we're using `Process.runSync()`. This changes many of the `Device` methods
to return `Future<T>` in order to allow them to use the async process
methods. A future change will add timeouts to the associated calls so
that we can properly alert the user to the hung `adb` process.
This is work towards #7102, #9567
There is a race where we could complete a future based on a stream event
and then before we cancel the stream subscription, we get another event
and try and complete the future again.
- [x] Switch the reassemble timeout to 5 seconds.
- [x] Print a status message if reassemble fails:
```
Performing hot reload...
Reassembling app.flx$main took too long. Hot reload may have failed.
Reloaded 0 of 418 libraries in 5,322ms.
```
Fixes#9316Fixes#8861Fixes#8857Fixes#8856
- [x] Catch SocketErrors and handle them gracefully.
- [x] Print 'Lost connection to device' when the service protocol connection is severed unexpectedly.
- [x] Print 'Application finished' when the application exits otherwise.
After this PR:
```
Launching lib/main.dart on Nexus 7 in debug mode...
Running 'gradle assembleDebug'... 1.2s
Built build/app/outputs/apk/app-debug.apk (21.7MB).
Syncing files to device...
Application finished.
DevFS sync failed. Lost connection to device: SocketException: OS Error: Connection refused, errno = 111, address = 127.0.0.1, port = 53062
Could not perform initial file synchronization.
```
Fixes#6705
- [x] Skip scanning the file system if we already have the Dart dependency set.
Fixes#9376
```
Performing hot reload...
Reloaded 1 of 418 libraries in 888ms.
Performing hot reload...
Reloaded 1 of 418 libraries in 871ms.
** UNTAR dragontail under project root **
Performing hot reload...
Reloaded 0 of 418 libraries in 443ms.
** UNTAR dragontail under lib/ **
Performing hot reload...
Reloaded 0 of 418 libraries in 385ms.
```
The first hot reload does a bunch of work that we used to hide behind the
loader screen. This PR changes the messsage printed to the user on the first
reload from:
'Performing hot reload...'
to:
'Initializing hot reload...'
Subsequent reloads say 'Performing hot reload...'
When invoked from the command line, relative paths aren't typically
used, but they are when invoked from within IDEA and prevents
IDEA from reading the files.
Also, remove flutterPackagesDirectory since it's not used
Generates an android.iml file and a package-level library for flutter.jar.
Does not set up an Android SDK in IDEA; this isn't possible with a
template-based approach. But IDEA shows a clear warning, so the
user can fix this by setting the SDK.
(When creating a Flutter project from within IDEA, we can fix this up
afterwards in the plugin.)
* Fix tests to use Ahem, and helpful changes around that
- Fix fonts that had metric-specific behaviours.
- LiveTestWidgetsFlutterBinding.allowAllFrames has been renamed
to LiveTestWidgetsFlutterBinding.framePolicy.
- LiveTestWidgetsFlutterBinding now defaults to using a frame policy
that pumps slightly more frames, to animate the pointer crosshairs.
- Added "flutter run --use-test-fonts" to enable Ahem on devices.
- Changed how idle() works to be more effective in live mode.
- Display the test name in live mode (unless ahem fonts are enabled).
- Added a toString to TextSelectionPoint.
- Style nit fixes.
* Roll engine to get Ahem changes.
* Update tests for dartdoc changes.
* Fix flutter_tools tests
Rename State.config to State.widget
Rename State.didUpdateConfig to State.didUpdateWidget
Renamed all State subclasses' local variables named config to something else
Added a PluginRegistry to the new project template. The registry files will be automatically updated at build time to register the native plugins.
Fixes#7814.
This yak shave went as follows:
Fix https://github.com/flutter/flutter/issues/8795 by adding stocks to
the examples README.
Notice the layers entry in that README isn't quite right either.
Update that.
Check the layers/README file is worth pointing at.
Update the layers/README.
Let's run some of the layer tests to see if they still work.
Oops, need to update them to gradle.
Ok let's try running them again.
Oops, sector is broken.
Add a test for sector.
Fix sector. Find you need to add an assert to a const constructor.
Notice we need to turn const asserts on for the analyzer.
Notice the analysis_options files are out of sync with each other and
with the full list of lints.
Turn on the lints that should be on.
Fix the bugs that finds.
* Roll Dart to 1.23.0-dev.11.3.
This is expected to fix the Windows crashes reported in https://github.com/flutter/flutter/issues/8912.
* fix tests
* Roll to 1.23.0-dev.11.5
* Fix tests
This package now depends on collection and quiver. The package level
dependencies in the BUILD.gn file should match the list of dependencies
in the pubspec.yaml file for the Fuchsia build to function.
Uninstalling the app removes the data and cache directories, so this
allows application data to persist across multiple flutter run
invocations.
This also handles the edge case where the app fails to install due to an
error in installation (e.g. debug keystore changes, switching from a
release keystore to a debug keystore, etc.).
Gradle projects are evaluated in lexicographical order, and the plugin
projects are at the same level as the :app project, so if a plugin has
a name that comes before 'app' (like, for example, any name that starts
with a capital letter), the plugin project will be evaluated before
:app.
Since :app applies the Flutter Gradle plugin, which tries to
modify the dependencies of the plugin projects, we have a problem if the
plugin projects have already been evaluated. Adding
evaluationDependsOn(':app') to the plugin projects fixes this.
Updated example projects to the latest (plugin-enabled) Gradle build
files.
Also removed two unused imports in `pluginClass.java.tmpl`.
Xcode builds depend on the Python 'six' module. If not present, exit
immediately with a useful error message.
The six module is included in the system default Python installation. We
perform this check in case a custom Python install has higher priority
on $PATH; e.g., due to a Homebrew or MacPorts installation.
This extracts an existing doctor check to use it during the build step
as well.
Plugin projects are created by running `flutter create --plugin <name>`.
An example app is also created in the plugin project, using the normal 'create' template, which has been modified to allow for conditional plugin code.
Modified the android package name to match package naming conventions (all lower-case, and must match the directory name).
* Bump to Dart SDK 1.23.0-dev.10
* allows us to understand flutter usage via telemetry
* brings in `@immutable`
Fixes: #9042
* completer fix
* Update to platform 1.1.1.
The very first time `pod install` is invoked, CocoaPods downloads the master spec repository, which takes quite a while. Before this change, the build appeared to have stalled. With this change, at least the spinner is moving.
Added `pod setup` to the install instructions for CocoaPods, so the spec repo is downloaded while setting up Flutter, instead of during the first build.
Old Android Stuio versions pior to 2.2.0 didn't come with Java bundled. Make sure flutter doesn't crash when we try to determine the Java version of those old Android Studio installations.
Go through all packages brought in by pub, and write the name and path of every one that is a flutter plugin into .flutter-plugins.
In android/settings.gradle and ios/Podfile, read in .flutter-plugins, if that file exists. The Android / iOS code from the plugins is automatically added as dependencies of the native code of the app.
**THIS IS A BREAKING CHANGE.** See below for migration steps for
existing projects.
Previously, Flutter app code was built as a raw dylib on iOS. Dynamic
libraries outside of a framework bundle are not supported on iOS, except
for the system Swift libraries provided by Xcode.
See:
https://developer.apple.com/library/content/technotes/tn2435/_index.html#//apple_ref/doc/uid/DTS40017543-CH1-TROUBLESHOOTING_BUNDLE_ERRORS-EMBEDDED__DYLIB_FILES
* Migrates Xcode build from app.dylib to App.framework
* Migrates flutter create template
* Migrates example projects
Migration steps for existing projects
=====================================
The following steps should be taken from the root of your Flutter
project:
1. Edit `ios/.gitignore`: add `/Flutter/App.framework` on a new line.
2. In the Xcode project navigator, remove `app.dylib` from the Flutter
folder. Delete this file from the `ios/Flutter` directory in your project.
3. Run a build to generate `ios/Flutter/App.framework`. From the command
line, run `flutter build ios`. If you have not configured app signing
in Xcode, an alternative method is to open the simulator, then run
`flutter run -d iP`.
4. In the Xcode project navigator, select the `Runner` project. In the
project settings that are displayed in the main view, ensure that the
`Runner` target is selected. You can verify this by exposing the
sidebar using the [| ] icon in the upper-left corner of the main
view.
5. Select the *General* tab in the project settings. Under the
*Embedded Binaries* section, click '+' to add `App.framework`. In the
sheet that drops down, click the *Add Other...* button. Navigate to
the `ios/Flutter` directory and select `App.framework`. Click *Open*.
In the sheet that drops down, select *Create folder references*, then
click *Finish*.
6. In the project settings, verify that `App.framework` has been added to the
*Embedded Binaries* and *Linked Frameworks and Libraries* lists.
7. In the Xcode project navigator, drag `App.framework` under the
Flutter folder.
8. In the Xcode project navigator, select `Flutter` then from the
*File* menu, select *Add Files to "Runner"...*. Navigate to the
`ios/Flutter` directory, select `AppFrameworkInfo.plist` and click
the *Add* button.
9. From the command line, in your project directory, run
`flutter build clean`, then `flutter run`.
At this point your project should be fully migrated.
* Teach flutter_tools to populate PUB_ENVIRONMENT
Will allow telemetry reporting on pub.dartlang.org once
flutter moves to 1.23.0-dev.10.0
* review changes
* Revert "use color.shadeXxx instead of color[Xxx] (#8932)"
This reverts commit 578ca0a295.
* Revert "add missing const keyword (#8931)"
This reverts commit fac2fac1d6.
* Revert "Make min/max fling velocity and min fling distance ScrollPhysics properties (#8928)"
This reverts commit dac80aac89.
* Revert "Defer to operating system for whichAll (#8921)"
This reverts commit 14933de986.
* Revert "Update gradle wrapper and build-tools version for flutter create. (#8914)"
This reverts commit deb71cc6dc.
The old `whichAll` implementation was not considering different extensions for executables on Windows. By defering to OS-built-in tools we avoid implementing it.
Fixes#8882.
* Update gradle wrapper and build-tools version.
Tested manually by "flutter create" with Idea "flutter run" and from android studio "run" android app.
* Update com.android.tools.build to 2.3.0
* Remove legacy .apk build.
Print out an error message telling the user to upgrade the project if
it's not Gradle-based. Removed all the obvious traces of the legacy
build.
Added support for Dart VM kernel snapshots in Gradle builds.
Fixed Android installs to verify that the app is actually installed, and
not just rely on the presence of the .sha1 file.
The problem has been fixed upstream in the Dart VM.
This simplifies our setup instructions on Windows (will update the wiki).
Furthermore, this also means that going forward there is no diffrence between PowerShell and Cmd for the Flutter experience on Windows.
Function keys don't work great on any platform we support:
* Mac doesn't have first-class function keys.
* On Ubuntu: F1 opens the system help and F10 opens the file dialog.
* ... and Windows is a mess as well.
* Only run pod install if CocoaPods v1.0.0 or greater is installed.
Avoid issues with older versions of CocoaPods breaking the build. Users who genuinely use older versions of CocoaPods will have to run pod install manually when required.
* Make ProcessSignals portable
This removes the need to wrap unsupported signals with in `if (!platform.isWindows) ..`.
It also allows us to implement a work around for breaking the Windows console when flutter is exited with Ctrl+C.
* review comments
* adding tests
* add license header
Changed the default build output directory in the new project template
to build/, instead of android/build/ and android/app/build/.
Updated tools to ask the Gradle scripts what the build directory is,
since this is configurable in the build scripts, and we need to know
where the build output actually is.
Silenced output from 'flutter build aot' when invoked from Gradle, since
the output was confusing in this case.
Fixes#8723Fixes#8656Fixes#8138
1. Add `PortScanner` abstraction so that we don't do actual port scanning
in tests.
2. Don't change the real `cwd` of the isolate during tests, as it affects
all tests, not just the current running test.
Fixes#8761
- [x] Add custom logic on MacOS to determine if Java is installed before invoking `java`.
- [x] Check JAVA_HOME, platform specific logic, and finally PATH to locate the `java` executable.
- [x] Improved doctor messages.
Fixes#8508Fixes#8521
* Use snapshot's .d file as source inputs in Gradle build.
If we don't yet have a .d file (first build), fall back to using the
.dart files in the current directory. This enables us to detect changes
in dependent source files (Flutter framework, packages outside the
source directory, etc.), and re-generate the snapshots as needed.
Unfortunately, Gradle requires knowing the source files before executing
the task, and can't update them after building, so Gradle considers the
second build to be out-of-date (because it has more input files than the
first build). Sub-sequent builds have the correct dependency
information, and will be skipped if the source files haven't changed.
Also added a dependency on gen_snapshot. The snapshot ABI isn't stable,
so we need to re-generate the snapshots when we roll the Dart SDK
dependency.
Fixes#8315Fixes#8687Fixes#8607
It was resulting in weird situations where the tool would dump an
error message and stack but not quit, or would fail hard but then just
hang.
Instead, specifically catch errors you expect. As an example of this,
there's one error we expect from the DartDependencySetBuilder, so we
catch that one, turn it into a dedicated exception class, then in the
caller catch that specific exception.
* Revert "Eliminate CocoaPods install step (#8694)"
This reverts commit f4a13bc72b.
If the developer is relying on CocoaPods and hasn't done a pod install, we will do it for them. This is needed for a smooth native plugin experience, similar to what Gradle is doing on the Android side.
There's no hard dependency on CocoaPods. We only run pod install if the project uses CocoaPods, so developers are still free to use alternatives if they prefer (and if they don't want to use native plugins).
Fixes#8685Fixes#8657Fixes#8526
* Require CocoaPods 1.0.0 or newer.
And make sure we don't get a crash if running `pod install` fails.
* Address review feedback
If the developer is relying on CocoaPods and hasn't done a pod install,
they'll get a build failure indicating the issue.
This also avoids a hard dependency on CocoaPods in the tool and allows
developers to customize their Xcode steps to use alternatives such as
Carthage if they prefer.
As of the latest Xcode versions, the latest published libimobiledevice
is out-of-date and build from HEAD is required.
This fixes two bugs:
1. Update initial install instructions to add --HEAD flag.
2. Update uninstall, reinstall instructions to include
--ignore-dependencies flag, since other brew formulae depend on
libimobiledevice.
Since iOS builds are CocoaPods enabled by default, we should make sure to run `pod install` to get pods wired up before building the app.
Also added a check to `flutter doctor` to verify CocoaPods is installed.
I'm passing FLUTTER_FRAMEWORK_DIR to the `pod install` command, so we can have the app's Podfile link in Flutter.framework as a pod instead of having to copy it over in xcode_backend.sh.
This implements the `DartDependencySetBuilder` completely in Dart instead of calling out to `sky_snapshot` (Linux/Mac) or `gen_snapshot` (Windows) and allows us to use the same code path on all supported host platforms.
It also slightly reduces hot reload times on Linux from ~750ms to ~690ms for the unchanged flutter_gallery app and significantly reduces hot reload times on Windows from almost 1.5s to just slightly slower than on Linux.
This change will also allow us to retire `sky_snapshot` completely in the future.
1. Add matchers for the `ProcessExit` exception class
2. Add ability to control the setup of the `AppContext` we use in
`testUsingContext()`
3. Clean up the code that figures out the location of `Cache.flutterRoot`
such that it works with `pub run test`. It previously only worked
when the tests were invoked with standalone `dart`
`#3` above will also help unblock #7941
* Small update to instructional comments in app template
* Update Flutter Driver comment
Good suggestion to add the link, Seth! I also updated the working to match what that page uses.
* add crash reporting without enabling it
* do not drop futures on the floor
* return exitCode from executable run
* debug travis
* remove unnecessary todo
* rename local fs getter
* Enable Hot Reload on Windows (backed by gen_snapshot)
\o/
Two caveats:
* Hot Reload on Windows is slower than on other platforms because gen_snapshot is slower then sky_snapshot
* We currently cannot hot reload projects with spaces in the path
* enable tests
The gradle build scripts can be configured to output different
application IDs for different build types, so we need to examine the
built .apk to figure out the name of the package and activity.
Re-landing this change, updated to only get information from the .apk
if it exists.
Since the tools create an AndroidApk instance early, even before we've
actually built an .apk, we have to create a new instance after building,
so we can start the right app/activity.
Fixes#8327.
* [devFS] Use URI to represent paths on device
Previosuly, regular file paths in the format of the host platform were used to represent paths on device. That works when host and device share the same (POSIX) file path format. With a Windows host, this breaks. URIs are the solution as they are platform independent and the VM service on the device already interpreted the file paths as URIs anyways.
* review comments
* switch to file paths
* fix tests on Windows
* review comments
* Revert "Revert "Simplify path handling logic in dependency checker and devFS (#8414)" (#8467)"
This reverts commit 96ba7f76d2.
* Intentionally use a self-package URI in flutter_gallery
* tests to catch problems with self-package imports
This adds support for a `--bug-report` flag, which is a recording
that:
- includes the arguments that were passed to the command runner
- is zipped up for easy attachment in Guthub issues
* Simplify path handling logic in dependency checker and devFS
Simplification will make it easier to port this to Windows.
* Roll Engine to 0a7b177c330367904597a6129b3eb653d29dfca0
The gradle build scripts can be configured to output different
application IDs for different build types, so we need to examine the
built .apk to figure out the name of the package and activity.
Fixes#8327
It's not just $HOME/.AndroidStudio2.2, it might also be
.AndroidStudioPreview2.3, or .AndroidStudioFooBar1.7, or whatever.
Made the Version parser less throw-happy, and relaxed the directory name
checks to allow for the above.
Fixes#8353.
* Bump to test `0.12.20`.
Some test `0.12.20` highlights:
* introduces `expectLater()` that returns a `Future` that completes when the matcher has finished running
* deprecates the `verbose` parameter to `expect()` and the `formatFailure()` (to be removed in `0.13.0`)
Otherwise:
* to keep up w/ the deprecation of `verbose`, removes `widget_tester` API to pass `verbose` flag (alternatively we could suppress the warning for now)
* Update stack manipulation.
* Fix framecount.
If a target file is specified on the flutter tools command line, pass it
through to Gradle.
It is still possible to statically specify a target file in the flutter
section of build.gradle, but it is now possible to specify it on the
command line as well. The command line option takes precedence.
Fixes#8175.
Only implemented for Android devices for now. Compare the installed SHA1
to the latest build. If they match, there's no reason to reinstall the
build.
Fixes#8295
* Fix bug parsing Gradle version.
Version from pub_semver requires versions of the format X.Y.Z. Gradle
doesn't follow semantic versioning, though, so version parsing would
fail on versions like '3.2'. Fixed by writing a custom Version class.
Also removed a check for apksigner when building Gradle-based projects.
Fixes#8298
Do not attempt to deploy/debug wifi connected iOS devices. ios-deploy is
able to install over wifi, but we've had several bugs reporting failure
to run/debug once installation has completed when the device is also
connected via USB. Note that we don't currently support deploy/debug
over wifi since libimobiledevice (which is also required) requires a USB
connection.
* Remove SHA1 check from AndroidDevice.isAppInstalled()
The docs for isAppInstalled say 'check if a version of the given app is
already installed', however the current code returns true only if it's
the latest build that's installed.
This made sense in the past, when the use pattern was:
if (!isAppInstalled(...)) installApp(...);
but now the usage is:
if (isAppInstalled(...)) uninstallApp(...);
installApp(...);
This has the probably unintended consequence that if you run `flutter
install` or `flutter run` two times in a row with no source changes, the
second invocation will uninstall the app, but the first invocation might
not.
Removing the SHA1 check makes us always uninstall the app if it's
installed.
Fixes#8172
* Teach flutter tools to find gradle
Flutter tools will now use Gradle from Android Studio, which is now found automatically.
flutter doctor will verify that Android Studio has been installed, and that the included Gradle is at least version 2.14.1.
It is still possible to manually configure the path to Android Studio (flutter config --android-studio-dir=XXX) or Gradle (flutter config --gradle-dir=XXX), but this should only be necessary if they're installed somewhere non-standard.
Only tested on Linux and macOS for now.
Fixes#8131
* Do not attempt to merge non-fat frameworks in Xcode build
During the Xcode build, we strip code irrelevant to the target
architecture in frameworks used by the application. In the case of
non-fat executables, no stripping occurs, so the frameworks can be used
as-is. No merge & replace step is necessary.
* fixup! Do not attempt to merge non-fat frameworks in Xcode build
Artifacts are now located in a central place.
This will enable us to downlaod artifacts when we need them (instead of
downloading them all upfront).
This also makes replacing sky_snapshot with gen_snapshot easier.
If a developer has installed the Xcode command-line tools, then later
installs Xcode, they may need to run xcode-select to update the path of
the command-line tools to that of the new installation.
The "old" APK build did not include Roboto fonts, but the new
Gradle-based build did. This is due to `flutter build flx` defaulting to
include the fonts, where the old `flutter build apk` defaulted to NOT
include them.
So let's change the Gradle build to also not include Roboto fonts.
Fixes#8149
On flutter run, we update ios/Flutter/Generated.xcconfig with various
Flutter-specific settings required by xcode_backend.sh during a build
from Xcode. These settings need to be present at the time the project is
loaded since Xcode doesn't pick up live updates to these files.
Without these settings, Xcode fails to locate xcode_backend.sh itself,
causing the build to fail until the Xcode project has been closed and
re-opened. This also prevents Xcode's project updater from 'helpfully'
suggesting to clean up and delete the Generated.xcconfig file.
* Make new project template gradle-based for Android.
With this change, the 'new project' template uses the same gradle-based build for Android as the hello_services example. This has some implications on build performance, since we're now building a complete Android app instead of just combining a pre-compiled .dex with the Flutter assets.
The very first build is a little over 2x slower, since it needs to download gradle and build the build scripts before getting to the actual code. Subsequent builds with changes to the code are comparable to the old builds. Null builds are faster. Enabling the gradle daemon speeds up subsequent builds by around 5s.
* Move Flutter Gradle plugin to Flutter root.
Required to handle Flutter SDK (and other) paths that include spaces.
Also includes general cleanup:
* Declare explicitly that we use /bin/bash, since we rely on its
features.
* Add -- where possible, to avoid interpreting files starting in - as
options.
* Suppress output of pushd/popd.
* Avoid stringifying arrays.
* Fix potential NPE in iOS doctor check
In case Xcode is not installed, the xcode-select path may be null.
* fixup! Fix potential NPE in iOS doctor check
If the developer has only installed the Xcode command-line tools,
xcode-select and some other tools may be present, but xcodebuild will be
missing. In this case, output a slightly improved message indicating
that the installation is incomplete rather than missing.
Support for thinning app frameworks to the target architecture was added
in 708909fc6b. This commit adds support
and error-checking for non-fat frameworks that are not of the target
architecture. In such cases, we now fail the build, and emit an error
message and the contents of lipo -info for the affected framework.
* Support thinning iOS frameworks to supported architectures
When building against frameworks that are distributed as
multi-architecture fat binaries, we want to strip the frameworks we
distribute down to only the architectures specified in $ARCHS.
This patch adds:
* The ability to specify commands to xcode_backend.sh (if none is
specified, run BuildApp for backward compatibility).
* A 'thin' command that invokes lipo to thin down the distributed as
described above.
* Add framework thinning step to iOS build
Invokes xcode_backend.sh thin on the build application.
* Limit architectures to arm64 in Xcode template
Flutter does not yet support armv7 iOS devices. Limit the $ARCHS build
variable to arm64 until then.
* Small Flutter strong mode cleanup fixes.
These are cases where strong mode down cast composite errors
generally indicated cases that would performance or correctness
issues if Flutter code was run in a strong mode VM.
* Fix Command API so that it is always in terms of Map<String,String>.
* Fix typedef
If ensureDirectoryExists fails -- e.g. because a file file of the same
name as the directory to be created exists, ensure that we exit cleanly
with a useful error message.
By default, pass status bar taps to the root view controller in
generated Flutter apps. Developers should customise as necesary if they
later create one or more alternate FlutterViewControllers that they'd
like to forward these to.
If the tool is started immediately after a previous run of the tool, then
the most recent log timestamp may come from the previous run's logs.
The new instance of the tool should not print those logs.
This was happening during runs of the microbenchmark script.
* Add doctor check for Python 'six' module
Required as part of Xcode lldb module. In all likelihood, if we
encounter this situation, the developer is using a custom Python install
(e.g., via MacPorts or Homebrew).
* Return null from VM.mainView if no view exists
* Retry in connectToServiceProtocol if a view is not yet available
* Do not explicitly call exit from the benchmarks - it will not cleanly shut down the engine
* Update gradle example to support x86 in debug mode.
Changed the Flutter Gradle plugin a bit to better fit in with the
Android build.
Fixes#6136Fixes#6864Fixes#7539
This remove a very brittle aspect of flutter drive, whereby it would
assume a known port instead of explicitly finding out what it was.
Fixes#7692 and hopefully fixes the devicelab tests.
Move the drive/run common stuff to RunCommandBase, rather than the
superclass which applies to everything.
Implement --no-resident (fixes
https://github.com/flutter/flutter/issues/5448). This is particularly
useful when running flutter from scripts.
Rename RunAndStayResident to ColdRunner.
* Add a check in case the flutter directory in .packages no longer exists. Clean up and prompt user
* Update documentation to use flutter packages get for end-users instead of flutter update-packages.
* Merge missing sdk error with the multiple sdk error. They're really the same thing.
* Use flutterPath in both checks.
* Change file_system’s copy folder to copy director which takes into account the file system
* Test support files
* Add test and split into 2 messages again.
* Move tests to run in memory file system's copy. Tested with dev/bots/test.sh
The zip files downloaded from cloud storage are not clearly separated
into engine artifacts and tools anyways.
Also, because of this unclear separation, we were downloading
`linux-x64/artifacts.zip` twice before.
* Change file_system’s copy folder to copy director which takes into account the file system
* Address review comments.
Test with 2 different instances of file systems.
* Disable 'Show Excluded' by default
* Move .iml file inside .idea dir
* Remove pub and build excludions as they are automatically set by the Dart plugin
* Exclude .idea folder (new users will edit it through the IJ UI, not the file)
* Move .iml files into .idea dir to be consistent with template changes
* Add workspace.xml from new template to existing samples
* Update current examples to match template changes for excluding folders
* Add missing flutter.yaml to make sure there are no analysis errors
* Add back .pub and build excludeFolder tags per https://github.com/flutter/flutter-intellij/issues/630#issuecomment-272887230
* Remove workspace.xml from example per review feedback
Refactor DevFS so that it's easier to add new types of content such as kernel code
* add tests for DevFS package scanning
* add tests for DevFS over VMService protocol
* which covers _DevFSHttpWriter and ServiceProtocolDevFSOperations
* replace AssetBundleEntry and DevFSEntry with DevFSContent
* refactor to cleanup common code and replace some fields with locals
* rework .package file generation refactor away DevFSOperations.writeSource
* only update .package file if it has changed
* only write/delete/evict assets that have been changed/removed
Also, defer to test package for throttling (this will require a test
package update as well).
Also, add a lot more instrumentation to --verbose mode for tests, and
fix minor trivial things here and there, and add error handling in
more places.
Also, refactor how coverage works to be simpler and not use statics.
When a machine is heavily loaded, it can severely delay the time it
takes for the OS to start a process once it's asked to do so. Our
5 second timeout that we were giving the test process to connect
to the test harness seemed like plenty of time, were it not for the
fact that the test process itself was not being started in time when
CPU throttling was in effect.
This change updates the test timeout to begin counting only once the
test process has been started. We keep the original timeout in play
in the event that the test process *never* starts up for some reason,
but we up that timeout value to 5 minutes.
Stop building (unused) unlinked summaries for packages.
Improves update speed considerably (for `n` packages it saves us `n` needless calls to `pub get`).
Previously, it was possible for the test harness to bail
and the test runner to complete before the platform plugin
triggered the collection of coverage data. This fixes the
race condition such that the pending coverage collection
task is recorded immediately after starting the process.
As of Dart SDK 1.22.0-dev.5.0, `Process.exitCode` is no longer
mutable (that SDK version picks up e5a16b1ca5).
This change allows the tools code to pass analysis in sdk versions both
before and after that change, to allow for analysis against both the host and
target sdks.
We now produce a more reasonable error message when we're missing the
flutter_test dependency in a test. Also, remove the flutter_tools stack traces
when the engine dies.
Fixes#6187
Each stack trace will yield many async task stacks for every write request
that is in flight. If the device side is unresponsive and all writes are
failing, then this can generate an overwhelming amount of logs.
Fixes https://github.com/flutter/flutter/issues/7351
When a test runs to completion, the test harness closes the stream side of the
StreamChannel, causing the sink side to be closed as well. So by the time we
receive a test result of completed/harnessBailed, the controller sink has been
closed.
This removes direct file access from within flutter_tools
in favor of using `package:file` via a `FileSystem` that's
accessed via the `ApplicationContext`.
This lays the groundwork for us to be able to easily swap
out the underlying file system when running Flutter tools,
which will be used to provide a record/replay file system,
analogous to what we have for process invocations.
- [x] Introduce DependencyChecker which can determine if any dependencies have been modified.
- [x] Move the DartDependencyBuilder into a separate file.
- [x] Add unit tests for DartDependencyBuilder.
- [x] Add unit tets for DependencyChecker
Part of #7014
Without this, an FLX with no assets may be completely empty in AOT mode.
This will result in a warning when the engine's unzip library tries to
parse the FLX.
Fixes https://github.com/flutter/flutter/issues/7060
This fixes an infinite loop in the code that walks the parent
context chain looking for a variable.
This also includes a fix in build_info.dart whereby if the context
is set but the config is not yet set, we were trying to dereference
null.
* s/sky/flutter/ in Android templates
* update engine.version with a compatible engine version
* replace more SkyActivity references with FlutterActivity
This argument will enable mocking of os-layer process invocations,
where the mock behavior will come from replaying a previously-
recorded set of invocations. At the point of process invocation,
the key metadata for the invocation will be looked up in the
recording's manifest, and iff a matching record exists in the
manifest, the process will be mocked out with data derived from
the corresponding recorded process (e.g. stdout, stderr, exit code).
This moves the various copies of port forwarding code in the Device subclasses into the ProtocolDiscovery class.
* move port forwarding to a common location
* throw exception if protocol Uri is not discovered or port forwarding fails
* cancel discovery protocol subscriptions on iOS launches (wasn't happening before)
* fix iOS port forwarding to match other implementations
* add tests
It is not enabled by default in the VM because applications not launched via the tools may try to connect with the debugger. This causes the debugger and the IDE to hang on Mac.
* Add --record-to option to flutter tools
This option will cause flutter tools to record all process
invocations that occur and serialize their stdout and stderr
to files that get added to a "recording" ZIP file. This is
part of an effort to be able to test flutter tools in a hermetic
environment.
As a side-benefit, this recording should prove an excellent
attachment to any bug report.
With this change, they're run via instance methods on an object
obtained through the context. This will allow us to substitute
that object in tests with replay/record versions to allow us to
mock out the os-layer in tests.
