ios-deploy relies on LLDB.framework, which relies on /usr/bin/python and
the 'six' module that's installed on the system. However, it appears to
use the first version of Python on PATH, rather than explicitly
specifying the system install. If a user has a custom install of Python
(e.g., via Homebrew or MacPorts) ahead of the system Python on their
PATH, LLDB.framework will pick up that version instead. If the user
hasn't installed the 'six' module, ios-deploy will fail with a
relatively cryptic error message.
This patch pushes /usr/bin to the front of PATH for the duration of the
ios-deploy run to avoid this scenario.
This patch also removes checks for package six.
Neither Flutter nor any of its direct dependencies/tooling relies on
package six. ios-deploy depends on LLDB.framework (included with Xcode),
which relies on a Python script that imports this package but uses
whichever Python is at the front of the path. Flutter now invokes
ios-deploy with a PATH with /usr/bin forced to the front in order to
avoid this problem.
We could have retained the check out of paranoia, but this seems
unnecessary since it's entirely possible LLDB.framework may one day drop
this dependency, in which case I'd expect the base system install of
Python would likely drop it as well.
fuchsia_tester.dart still assumes Dart 1. Previously, it ran tests directly
from source, flutter_platform.dart automatically runs a kernel compile when
operating in Dart 2 mode, but this assumes a functional Dart SDK is available
in the artifacts directly, and fuchsia_tester.dart mocks out the artifacts
directory with an empty temp dir.
Remaining work is:
1. Get the frontend server building as a dependency on Fuchsia.
2. Patch fuchsia_tester.dart to use a valid Dart SDK and frontend server.
This also reverts migration to Dart 2 typedef syntax.
This reverts commit 6c56bb2. (#18362)
This reverts commit 3daebd0. (#18316)
Now that Dart 1 is turned off, reapplying my change to turn on the prefer_generic_function_type_aliases analysis option, and fix all the typedefs to Dart 2 preferred syntax.
Also eliminated the unused analysis_options_repo.yaml file and turned on public_member_api_docs in analysys_options.yaml.
No logic changes, just changing the typedef syntax for all typedefs, and updating analysis options.
* It's time to #deleteDart1 (#18293)
Eliminates support for Dart 1 in flutter_tools, and drops our Dart 1
benchmarks. All commands now run in Dart 1 mode only.
Eliminates --preview-dart-2 / --no-preview-dart-2 support.
* Fix indentation, remove no longer necessary .toList()
* Only push udpated kernel if >0 invalidated srcs
Eliminates support for Dart 1 in flutter_tools, and drops our Dart 1
benchmarks. All commands now run in Dart 1 mode only.
Eliminates --preview-dart-2 / --no-preview-dart-2 support.
Uses the `version` property from the `pubspec.yaml` file to set the corresponding fields in the `local.properties` file respectively in the `Generated.xcconfig` file.
The `--build-name` and `--build-number` options have changed. Now they trump the `version` property from the `pubspec.yaml` file.
If the `version` property is not set and the `--build-name` and `--build-number` options are not provided, the build command will not change the `local.properties` / `Generated.xcconfig` file.
When running with --local-engine, build single-architecture apps, rather
than what's declared in the Xcode project.
By default, Flutter creates Xcode projects that generate universal
binaries supporting both armv7 and arm64 processors. Since local engine builds
are all single-architecture, override the Xcode project's ARCHS setting
with the appropriate value for the specific engine.
NOTE: this assumes engine paths consistent with those used in the engine
repo: 32-bit iOS engine builds end in _arm, 64-bit builds do not.
Previously, Flutter did not support iOS devices with armv7 or armv7s
CPUs. We now support these devices. This eliminates the previous
hardcoded checks that prevented running on simulators of older devices.
We maintain the existing restriction on running on watchOS or tvOS
simulators.
If the developer changes their Xcode build settings and their project
has plugins, pod install is required, (e.g. to pick up changes to the
target architecture).
Similarly, manual edits to the Podfile should trigger a pod install.
* Use engine-built dart sdk
* Download dart-sdk from engine
* Move up deps to fix dart sdk constraint problem
* Update update_dart_sdk.ps1 for Windows
* Fix tests so they pass analysis
* More types for tests
* Roll engine
* Update dart sdk stamp location in flutter.bat
* Add newline
* 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
Apple encodes syslog entries using a 7-bit encoding where input UTF-8 bytes
are encoded as follows:
1. 0x00 to 0x19: non-printing range. Some ignored, some encoded as <...>.
2. 0x20 to 0x7f: as-is, with the exception of 0x5c (backslash).
3. 0x5c (backslash): octal representation \134.
4. 0x80 to 0x9f: \M^x (using control-character notation for range 0x00 to 0x40).
5. 0xa0: octal representation \240.
6. 0xa1 to 0xf7: \M-x (where x is the input byte stripped of its high-order bit).
7. 0xf8 to 0xff: unused in 4-byte UTF-8.
As there doesn't appear to be a system tool to decode these strings, we
implement here in Dart. If we're unable to decode a string (e.g.
decoding results in an invalid UTF-8 string), we fall back to emitting
the log line as-is.
* Revert "Revert "Enable developers to run pod from terminal directly and skip pod install if possible. (#13374)" (#13770)"
This reverts commit 0759043e47.
* some nits on cocoapods code
* put back the FLUTTER_FRAMEWORK_DIR env variable
* 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.
Add support for IOS_SIMULATOR_HOME environment variable in IOSSimulator.logFilePath
flutter_tools can be run on environments where the user's HOME directory
is not the root of the iOS simulators' configs. This change adds support
for such environments by allowing the caller to set the simulator root
directory via an environment variable.
1. Migrate simulator device log tailing to os_log toolchain
2. When the log tag (component) is available (iOS 11/Xcode 9), filter to
the set of log lines with tag 'Flutter'.
As of iOS 11 / Xcode 9, Flutter engine logs are no longer recorded in the
simulator's syslog file, which we previously read using tail -f. Instead
they're now accessible through Apple's new macOS/iOS os_log facility,
via /usr/bin/log, which supports a relatively flexible query language.
When run in non-interactive mode, /usr/bin/log buffers its output in 4k
chunks, which is significantly smaller than what's emitted up to the
point where the observatory/diagnostics port information is logged. As a
workaround we force it to run in interactive mode via the script tool.
This was introduced to suppress libMobileGestalt noise originating from
libsystem_asl.dylib. Commit 39680ebfbd
suppresses all application log messages not originating from the
app/engine iteself on iOS 10 and above. Since the log message in
question is only emitted on devices running iOS >= 10.3.0, this
blacklist no longer necessary.
On iOS 10 and above, suppress engine log messages from system components
other than Flutter. This eliminates a large amount of keyboard/plugin
related noise during edit-refresh development.
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).
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.
This patch supports basic filtering of log lines from physical iOS
devices, similar to existing functionality for iOS simulator logging.
This patch also suppresses the following two log messages which are
emitted at app startup on iOS 10.3 devices:
libMobileGestalt MobileGestaltSupport.m:153: pid 123 (Runner) does not have sandbox access for frZQaeyWLUvLjeuEK43hmg and IS NOT appropriately entitled
libMobileGestalt MobileGestalt.c:550: no access to InverseDeviceID (see <rdar://problem/11744455>)
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.
This reverts commit b2909a245a.
This resubmits the following patches:
1. Use Xcode instruments to list devices (#10801)
Eliminates the dependency on idevice_id from libimobiledevice. Instead,
uses Xcode built-in functionality.
2. Make device discovery asynchronous (#10803)
Migrates DeviceDiscovery.devices and all device-specific lookup to be
asynchronous.
* Revert "Make device discovery asynchronous (#10803)"
This reverts commit 972be9c8b4.
* Revert "Use Xcode instruments to list devices (#10801)"
This reverts commit 37bb5f1300.
This is to resolve a failure that looks related to a bad install of Xcode 8.0
on our build bots and should be reinstated when the infra issue is diagnosed
and resolved.
Instruments worked well when this was originally landed, and on the
following commit, but started failing two commits after this originally
landed. Manual invocation of instruments on the build host currently
results in:
```
dyld: Library not loaded: @rpath/InstrumentsAnalysisCore.framework/Versions/A/InstrumentsAnalysisCore
Referenced from: /Applications/Xcode8.0.app/Contents/Developer/usr/bin/instruments
Reason: image not found
Abort trap: 6
```
It appears the /Applications/Xcode8.0.app/Contents/Applications
directory (which contains Instruments) is missing on the host.
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.
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.
* 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
