Xcode 10 introduces a new build system which includes stricter checks on
duplicate build outputs.
When plugins are in use, there are two competing build actions that copy
Flutter.framework into the build application Frameworks directory:
1. The Embed Frameworks build phase for the Runner project
2. The [CP] Embed Pods Frameworks build phase that pod install creates
in the project.
Item (1) is there to ensure the framework is copied into the built app
in the case where there are no plugins (and therefore no CocoaPods
integration in the Xcode project). Item (2) is there because Flutter's
podspec declares Flutter.framework as a vended_framework, and CocoaPods
automatically adds a copy step for each such vended_framework in the
transitive closure of CocoaPods dependencies.
As an immediate fix, we opt back into the build system used by Xcode 9
and earlier. Longer term, we need to update our templates and
flutter_tools to correctly handle this situation.
See: https://github.com/flutter/flutter/issues/20685
This caused issues for projects without an Xcode workspace. Almost all
Flutter projects in the wild will have a workspace, but this patch needs
to add a check to catch any that lack one.
This reverts commit 021f472efc.
Xcode 10 introduces a new build system which includes stricter checks on
duplicate build outputs.
When plugins are in use, there are two competing build actions that copy
Flutter.framework into the build application Frameworks directory:
1. The Embed Frameworks build phase for the Runner project
2. The [CP] Embed Pods Frameworks build phase that pod install creates
in the project.
Item (1) is there to ensure the framework is copied into the built app
in the case where there are no plugins (and therefore no CocoaPods
integration in the Xcode project). Item (2) is there because Flutter's
podspec declares Flutter.framework as a vended_framework, and CocoaPods
automatically adds a copy step for each such vended_framework in the
transitive closure of CocoaPods dependencies.
As an immediate fix, we opt back into the build system used by Xcode 9
and earlier. Longer term, we need to update our templates and
flutter_tools to correctly handle this situation.
See: https://github.com/flutter/flutter/issues/20685
* Upgrade everything except matcher.
* Roll matcher (and test)
* Adjust tests that depend on flutter:test directly to depend on a shim
* Require use of package:test shim and remove other references to package:test
* Revert "Revert "Reduce xcodebuild noise #2" (#14641)"
This reverts commit 2d47481f1e.
* Stop scrapping xcodebuild output, get the right build settings
* clone the command params first
* Change async stubbing to use thenAnswer.
Mockito now prohibits calling thenReturn with Futures and Streams. dart-lang/mockito#79
* Update all Mockito deps to 3.0.0.
* Revert "Update all Mockito deps to 3.0.0."
This reverts commit e8ab9d37c3.
I did not correctly update the mockito dep, and there's no easy way to update to 3.0 alpha right now.
* Change thenAnswer((_) => to thenAnswer((invocation) =>
* Add Invocation type to thenAnswer lambdas
We now require Xcode 9.0, which ships with the iOS 11 SDK, for iOS
builds. This change does not affect the minimum supported iOS deployment
target, which remains iOS 8.
The iOS 11 SDK adds support for safe area insets, which model the status
bar, iPhone X home indicator, and symmetric horizontal insets to avoid
the iPhone X sensor housing when in landscape mode.
This re-lands flutter/flutter#13608 now that the devicelab Macs have
been updated to Xcode 9.
We now require Xcode 9.0, which ships with the iOS 11 SDK, for iOS
builds. This change does not affect the minimum supported iOS deployment
target, which remains iOS 8.
The iOS 11 SDK adds support for safe area insets, which model the status
bar, iPhone X home indicator, and symmetric horizontal insets to avoid
the iPhone X sensor housing when in landscape mode.
This patch migrates iOS device listing from using Xcode instruments to
using the libimobiledevice tools idevice_id and ideviceinfo.
ideviceinfo was previously incompatible with iOS 11 physical devices;
this has now been fixed.
In 37bb5f1300 flutter_tools migrated from
libimobiledevice-based device listing on iOS to using Xcode instruments
to work around the lack of support for iOS 11. Using instruments entails
several downsides, including a significantly higher performance hit, and
leaking hung DTServiceHub processes in certain cases when a simulator is
running, necessitating workarounds in which we watched for, and cleaned
up leaked DTServiceHub processes. This patch returns reverts the move to
instruments now that it's no longer necessary.
In some cases, we've seen interactions between Instruments and the iOS
simulator that cause hung instruments and DTServiceHub processes. If
enough instances pile up, the host machine eventually becomes
unresponsive.
Until the underlying issue is resolved, manually kill any orphaned
instances (where the parent process has died and PPID is 1) before
launching another instruments run.
Previously, xcodeMajorVersion and xcodeMinorVersion returned null unless
xcodeVersionSatisfactory had been called first. We now compute them on
demand, and cache the resultant values.
Moves all remaining calls to tools that are part of the libimobiledevice
suite of tools to the IMobileDevice class. This allows for better
tracking of this dependency, and easier mocking in tests.
* Before tests
* Add the part to trust the cert on the device
* flip the error checks since some are more specific and are more actionable
* add tests
* review
