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.
* Plumb a --strong option through to the front end server and the engine
so that we can run flutter apps in preview-dart-2 and strong mode
* - Address analyzer lint issues
*- correctly set up strong mode option in the case of AOT builds
* 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
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.
* Revert "Include a directory with Flutter assets (#12944)"
This reverts commit 3af6b9cbf5.
* Revert "Upgrade project.pbxproj to include flutter_assets (#13011)"
This reverts commit 08128cb29b.
* Revert "Upgrade complex_layout project.pbxproj to include flutter_assets (#13544)"
This reverts commit 35f1a04195.
* mark complex_layout_ios__start_up as flaky
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.
I got tired of drive-by spelling fixes, so I figured I'd just take care of them all at once.
This only corrects errors in the dartdocs, not regular comments, and I skipped any sample code in the dartdocs. It doesn't touch any identifiers in the dartdocs either. No code changes, just comments.
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.
On iOS 11.0.x ideviceinfo fails with the following message
ERROR: Could not connect to lockdownd, error code -3
This workaround should also work for #12330
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.
* Add --trace-skia parameter to flutter run
Skia tracing is extremely useful for internal debug, but reduces the
amount of space available in the Dart Timeline buffers.
Disable skia tracing by default and expose them via the --trace-skia
flag.
* Roll Engine to 57a1445a45964d386500c39f5e8d06db060abadb
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).
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.
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 allows us to take advantage of improved command-line tooling (e.g.,
improvements in device listing in Instruments). Now that the engine is
built with Xcode 8 and the framework is tested against Xcode 8, this
reduces the set of configurations we need to support to allow us to
focus on the supported ones: Xcode 8 and Xcode 9.
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.
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.
This code is unused in any test. In upcoming changes that migrate to
Xcode instruments based device listing, we'll mock out the instruments
output separately.
* 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
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.
* first pass
* improvements
* extract terminal.dart
* rebase
* add default terminal to context
* The analyzer wants the ../ imports in front of the ./ imports
* review notes
For some reaosn, when we discovered our URI, we were re-instantiating
the `Completer` instance variable whose future we listen to in `nextUri()`.
This led to a race between a caller calling `nextUri()` and us discovering
the URI. If we happened to discover our URI before a caller called
`nextUri()`, then they would be left waiting on a future from the newly
allocated `Completer` (which would never complete).
Fixes#10064
