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