* 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).
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.
