The libimobiledevice suite of tools do not include version information.
A simple way to verify they meet our version requirements is to run
idevice_id -l, which will fail when older versions are run against iOS
devices with newer versions of iOS installed.
Unfortunately, idevice_id -l will also fail when libimobiledevice is up
to date, but the attached devices have never been paired with the host
machine in Xcode.
This patch updates the error message to help guide the user in such
situations.
ios-deploy 1.9.2 includes fixes for a common source of Xcode breakage
(flutter/flutter#4326) with Xcode 8.3.3 + iOS 10.3.3, and is required to
to support Xcode 9 (flutter/flutter#11875).
Opening Xcode is no longer sufficient to enable develop mode in Xcode 9.
Update the message to run the command-line tool. Alternatively users can
launch an app in the Xcode debugger to do this.
Use a top-level getter in mac.dart rather than a static instance getter
and a top-level getter in ios_workflow.dart. Makes this code consistent
with how we do context lookups elsewhere.
Extract out IMobileDevice class, move class to idevice_id, ideviceinfo
(and eventually other libimobiledevice tools such as iproxy) behind this
interface.
Add tests for the case where libimobiledevice is not installed, the case
where it returns no devices, and the case where it returns device IDs.
Eliminates the need for the device/daemon code to get at the iOS/Android
tooling indirectly via Doctor. In tests, we now inject the workflow
objects (or mocks) directly.
Eliminates nearly-duplicate install instructions for libimobiledevice,
ideviceinstaller.
Since ideviceinstaller depends on libimobiledevice, it's almost certain
that if libimobiledevice isn't installed, or needs updating, so does
ideviceinstaller.
This message will be emitted both when libimobiledevice requires
updating, or when it has not yet been installed.
It's also not specifically the version of Xcode that it's incompatible
with, it's the lockdownd daemon, which is actually more closely tied to
iTunes.
`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
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.
* 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.
* 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.
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.
