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.
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.
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.
* Allow for application-specific log readers.
When running with prebuilt application binaries, those applications
aren't guaranteed to be named "Runner" (as it is when we build
the app locally in Flutter tools)
* convert pubGet to throw ToolExit on non-zero exit code
* convert commandValidator to throw ToolExit for non-zero exit code
* convert flutter commands to throw ToolExit for non-zero exit code
* use convenience method throwToolExit
* only show "if this problem persists" for unusual exceptions
It takes a little bit longer that 10 seconds to install, launch and
have the observatory be available on an iPod touch. Depending on the
size of the application, it could be a lot longer to transer the
bundle over the wire. The 60 seconds is arbitrary.
Previously, overall status was reported as good if Xcode and homebrew
were installed, even if there were issues with either of the tools. We
now report partial status if we detect issues with either installation.
libimobiledevice 1.2.0 is incompatible with Xcode >= 8.0. Since the
libimobiledevice tools don't include a --version flag, check for valid
exit code on running idevicename, if an iOS device is connected.
When using --use-application-binary:
- [x] Stop flutter run from checking for a pubspec.yaml in current directory
- [x] Stop flutter run from invoking pub get
- [x] Set 'shouldBuild' based on --use-application-binary
- [x] Stop requiring 'lib/main.dart' to be present before running.
- [x] Stop building an FLX when launching on Android
Ensure that we're monitoring logs before we launch the app on the
device. This prevents the case where we start monitoring after the ports
have already been logged.
Also update the regex to use an optional capture group.
With iOS 10, the syslog format changed from:
Sep 23 16:04:17 cbracken-iPhone Runner[6188] <Info>: .*
to:
Sep 23 16:04:17 cbracken-iPhone Runner(libsystem_asl.dylib)[6188] <Info>: .*
This updates the observatory port scraping to handle either case.
This change adds a top-level getBuildDirectory func and funcs for
android, aot, asset, ios build products.
Developers may now add a "build-dir" mapping to their
~/.flutter_settings (JSON format) config file. Output directory is
relative to the main flutter application directory.
This change also changes the default build directory for iOS builds to a
subdirectory of the configured build directory, 'build/ios' by default.
- [x] Refactor view support into separate classes.
- [x] Make the hot runner grab the main view and call runFromSource on it.
- [x] Remove Device.needsDevFS (because it is always true).
This patch changes the default `flutter create` command to generate a
HelloServices-style app on iOS. As a consequence, the Atom integration now
fully works with HelloServices.
The new `empty_statements` lint (in the next DEV roll), flags these empty statements. Harmless, except the one in `basic.dart` that fixes a real-life bug. :)
* working on making a faster flutter run restart
* clean up todos; fire events on isolate changes
* use the Flutter.FrameworkInitialization event
* review comments
* iOS tools cleanup
1) Fix `flutter install` on both device and simulator to refer to the actual
bundle and not just the .generated folder
2) Fix `flutter run` on device to actually run vs just installing
Still TODO:
1) Discovered that isAppInstalled on iOS simulator always reports true,
meaning it'll never actually try to install the app.
Fixes#3947Fixes#1823
This also fixes some related problems affecting "flutter run":
* FLXes built during AndroidDevice.startApp need to match the build mode
* APKs should always be rebuilt if the build mode uses AOT compilation
* rename service_protocol.dart to protocol_discovery.dart
* add a wrapper around the obs. protocol
* use json-rpc in run
* consolidate obs. code; implement flutter run --benchmark
* review comments
Host tools can be found in the artifact cache directory for the host platform.
If a developer wants to use a local engine build instead, then provide an
--engine-build flag that selects the specific engine build variant.
* more terse flutter upgrade
* fix an issue when updating and the engine update code has changed
* call flutter precache; add a --no-color hidden option
* fix a lint related to getters/setters
The new name format is "DEVICE_TYPE_NAME (Flutter)". For example:
iPhone 6 (Flutter)
iPhone 6s Plus (Flutter)
The names are taken from `xcrun simctl list --json devicetypes`.
Fixes#2682
flutter start's method of finding devices to run the app on is not suitable for flutter drive.
This commit also refactors several tool services to allow mocking in unit tests.
In case the user changes the path of the Flutter project on disk, the Dart SDK or the Flutter repository itself, the old Xcode paths would be invalid. Now, we rewrite them when we build the project.
