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