We decided that redefining the default for templates was premature. We're going to go back to having "module" in experimental land again, and we'll try again when we have the feature set fully baked.
This keeps the writing of the .metadata files, and writing the template type to them, because that was a good improvement, and there are still a bunch of added tests that improve our coverage.
This renames the "module" template to the "application" template, and makes "application" the default. The existing "app" template is now deprecated.
flutter create also now recognizes the type of project in an existing directory, and is able to recreate it without having the template type explicitly specified (although you can still do that). It does this now by first looking in the .metadata file for the new project_type field, and if it doesn't find that, then it looks at the directory structure. Also, the .metadata file is now overwritten even on an existing directory so that 1) the project_type can be added to legacy projects, and 2) the version of Flutter that updated the project last is updated.
I also cleaned up a bunch of things in create_test.dart, added many more tests, and added an example test to the test/ directory in the generated output of the application template.
Fixes#22530Fixes#22344
* Prototype
* Fix paths to Flutter library resources
* Invoke pod install as necessary for materialized modules
* Add devicelab test for module use on iOS
* Remove debug output
* Rebase, reame materialize editable
* Add devicelab test editable iOS host app
* Removed add2app test section
This changes the compiler output for gradle to be less verbose and more easily read.
This only applies to compilation error messages: other gradle messages will continue to print as before.
It also fixes a small problem with the performance measurement printing (see that "7.1s" on it's own line in the original?) so that if something is expected to have multiple lines of output, it prints an initial line, and a "Done" line with the elapsed time, so that it's possible to know what the time applies to.
It also updates the spinner to be fancier, at least on platforms other than Windows (which is missing a lot of symbols in its console font).
Addresses #17307
This adds support to AnsiTerminal for colored output, and makes all tool output written to stderr (with the printError function) colored red.
No color codes are sent if the terminal doesn't support color (or isn't a terminal).
Also makes "progress" output print the elapsed time when not connected to a terminal, so that redirected output and terminal output match (redirected output doesn't print the spinner, however).
Addresses #17307
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
* First step in Flutter Doctor refactor. Assigns categories to all validators.
* Revert "Roll engine e54bc4ea1832..a84b210b3d26 (6 commits) (#20453)"
This reverts commit 05c2880a17.
* Split iOS and Android workflows into workflow and validator classes.
* Change ValidatorCategory to handle standalone validators that share a
category (e.g. IntelliJ).
Also make Android Studio and Android toolchain use separate categories.
At this stage, flutter doctor output matches what it was previously.
(The summary() method itself has not yet been changed )
* Change doctor summary code to support validator categories.
Output is still unchanged.
* Handle small formatting issues.
* Flip Flutter category's isGroup field to false until it's actually
needed.
* Revert auto-generated formatting changes to keep those lines from
muddying the pull.
* Small fixes pointed out by analyzer.
* Properly fix analyzer issues around const constructors.
* Small changes to address comments.
* Add tests to verify grouped validator behavior and validationtype
merging.
* Update doctor.dart
* Add comments for clarification.
This patch eliminates the --preview-dart-2/--no-preview-dart-2 flag,
hardcoding all uses to true. It also defaults all previewDart2 method
parameters to true, where they hadn't yet been.
A series of subsequent patches will eliminate all previewDart2
parameters and the associated code from within the codebase.
All temporary directory start with `flutter_` and have their random component separated from the name by a period, as in `flutter_test_bundle.YFYQMY`.
I've tried to find some of the places where we didn't cleanly delete temporary directories, too. This greatly reduces, though it does not entirely eliminate, the directories we leave behind when running tests, especially `flutter_tools` tests.
While I was at it I standardized on `tempDir` as the variable name for temporary directories, since it was the most common, removing occurrences of `temp` and `tmp`, among others.
Also I factored out some common code that used to catch exceptions that happen on Windows, and made more places use that pattern.
Disallow calling stop() or cancel() multiple times. This means that
when you use startProgress you have to more carefully think about what
exactly is going on.
Properly cancel startProgress in non-ANSI situations, so that
back-to-back startProgress calls all render to the console.
Disallow calling stop() or cancel() multiple times. This means that
when you use startProgress you have to more carefully think about what
exactly is going on.
Properly cancel startProgress in non-ANSI situations, so that
back-to-back startProgress calls all render to the console.
* Only printError on our simple messages
Any other type is a real error that should be a normal crash (to get a proper error log).
See #19453.
* Add toList() to convert Iterable<String> -> List<String>
This code previously throw in Dart-2 mode.
Fixes#19453.
* Move getSimulatorPath into Xcode
* Add a test that we tried to launch the simulator
* Remove unused import
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.
* Add --create option to flutter emulators
* Tweaks to error message
* Simplify emulator search logic
* Make name optional
* Add a note about this option being used with --create
* Tweaks to help information
* Switch to processManager for easier testing
* Don't crash on missing files or missing properties in Android Emulator
* Move name suffixing into emulator manager
This allows it to be tested in the EmulatorManager tests and also used by daemon later if desired.
* Pass the context's android SDK through so it can be mocked by tests
* Misc fixes
* Add tests around emulator creation
Process calls are mocked to avoid needing a real SDK (and to be fast). Full integration tests may be useful, but may require ensuring all build environments etc. are set up correctly.
* Simplify avdManagerPath
Previous changes were to emulatorPath!
* Fix lint errors
* Fix incorrect file exgtension for Windows
* Fix an issue where no system images would crash
reduce throws on an empty collection.
* Fix "null" appearing in error messages
The name we attempted to use will now always be returned, even in the case of failure.
* Add additional info to missing-system-image failure message
On Windows after installing Andriod Studio I didn't have any of these and got this message. Installing with sdkmanager fixed the issue.
* Fix thrown errors
runResult had a toString() but we moved to ProcessResult when switching to ProcessManager to this ended up throwing "Instance of ProcessResult".
* Fix package import
* Fix more package imports
* Move mock implementation into Mock class
There seemed to be issues using Lists in args with Mockito that I couldn't figure out (docs say to use typed() but I couldn't make this compile with these lists still)..
* Rename method that's ambigious now we have create
* Handle where there's no avd path
* Add another toList() :(
* Remove comment that was rewritten
* Fix forbidden import
* Make optional arg more obviously optional
* Reformat doc
* Note that we create a pixel device in help text
* Make this a named arg
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)
* 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.
I can't come up with a better name; anything with Simulator or Device in it will be confused with the existing IOSSimulator/Device classes (which represent the running devices).
This change adds support for armv7, arm64, and universal iOS apps.
This change eliminates iOS target architecture hardcoding (previously
arm64 only) and uses the target architecture(s) specified in Xcode's
ARCHS setting ('Architectures' in Xcode Build Settings).
For universal binaries, set ARCHS to its default value, $(ARCHS_STANDARD).
Note that after changing the architecture in Xcode, developers should
run 'pod install' from the ios subdirectory of their project. A separate
change (that will land before this one) will add support for
automatically detecting project file and Podfile changes and re-running
pod install if necessary.
This change also adds an --ios-arch option to flutter build aot. In iOS
AOT builds (in profile and release mode), this dictates which
architectures are built into App.framework. This flag should generally
be unnecessary to set manually since flutter build aot is typically only
invoked internally by flutter itself.
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.
iOS debug builds always run in interpreted mode whether on device or on
simulator. In both cases, we can skip snapshotting and link against an
empty App.framework. Previously, we did this for iOS simulator builds.
This does the same for device builds.
Previously, debug iOS builds used gen_snapshot to generate a core
snapshot, then used 'xxd' to generate C files containing the snapshot
data in buffers named kDartVmSnapshotData and kDartIsolateSnapshotData,
which are then compiled/linked into App.framework. This is unnecessary
since the VM compiled into Flutter.framework already contains this data.
* Revert "Revert "Add android license verification to doctor and some refactoring" (#14727)"
This reverts commit d260294752.
* Add tests, fix sdkManagerEnv and use it consistently, and rearrange Status object model
* AnsiSpinner needs to leave the cursor where it found it.
* fix tests
* Const constructor warning only shows up on windows...?
* Avoid crash if we can't find the home directory
* Make pathVarSeparator return a string in the mock
* Implement review comments
* Fix out-of-order problem on stop
* Created plumbing but has stream problem
* testing with makePipe
* Trying pipe but not really getting anywhere
* works by repeatedly reading line
* Minor cleanup
* works
* Clean up pipe after use.
* Move the last status forward
* Make sure failed script commands bubble up
* 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
* Reduce noise in xcodebuild stdout
* Reduce output from cleaning, from non failing xcode outputs and from script
* Check xcodebuild clean's exit code
* Revert "Reduce noise in xcodebuild stdout"
This reverts commit 222a26f55f.
Previously, the iOS ApplicationPackage subclasses did not mark the
bundleID constructor parameter as @required. This is passed up to the
ApplicationPackage constructor as the id parameter which is already
marked @required and is asserted to be non-null.
When diagnosing a failed Xcode build, if neither the development team
(for automatic provisioning) nor the provisioning profile (for manual
provisioning) is set, display the appropriate error message. Previously,
this method would not output the appropriate error message if a
only a development team was set.
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
* blind wrote everything except the user prompt
* works
* Add some logical refinements
* Make certificates unique and add more instructinos
* print more info
* Add test
* use string is empty
* review notes
* some formatting around commands
* add a newline
`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
* Fix tests to use Ahem, and helpful changes around that
- Fix fonts that had metric-specific behaviours.
- LiveTestWidgetsFlutterBinding.allowAllFrames has been renamed
to LiveTestWidgetsFlutterBinding.framePolicy.
- LiveTestWidgetsFlutterBinding now defaults to using a frame policy
that pumps slightly more frames, to animate the pointer crosshairs.
- Added "flutter run --use-test-fonts" to enable Ahem on devices.
- Changed how idle() works to be more effective in live mode.
- Display the test name in live mode (unless ahem fonts are enabled).
- Added a toString to TextSelectionPoint.
- Style nit fixes.
* Roll engine to get Ahem changes.
* Update tests for dartdoc changes.
* Fix flutter_tools tests
Added a PluginRegistry to the new project template. The registry files will be automatically updated at build time to register the native plugins.
Fixes#7814.
This yak shave went as follows:
Fix https://github.com/flutter/flutter/issues/8795 by adding stocks to
the examples README.
Notice the layers entry in that README isn't quite right either.
Update that.
Check the layers/README file is worth pointing at.
Update the layers/README.
Let's run some of the layer tests to see if they still work.
Oops, need to update them to gradle.
Ok let's try running them again.
Oops, sector is broken.
Add a test for sector.
Fix sector. Find you need to add an assert to a const constructor.
Notice we need to turn const asserts on for the analyzer.
Notice the analysis_options files are out of sync with each other and
with the full list of lints.
Turn on the lints that should be on.
Fix the bugs that finds.
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.
Go through all packages brought in by pub, and write the name and path of every one that is a flutter plugin into .flutter-plugins.
In android/settings.gradle and ios/Podfile, read in .flutter-plugins, if that file exists. The Android / iOS code from the plugins is automatically added as dependencies of the native code of the app.
* Remove legacy .apk build.
Print out an error message telling the user to upgrade the project if
it's not Gradle-based. Removed all the obvious traces of the legacy
build.
Added support for Dart VM kernel snapshots in Gradle builds.
Fixed Android installs to verify that the app is actually installed, and
not just rely on the presence of the .sha1 file.
* 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.
1. Add `PortScanner` abstraction so that we don't do actual port scanning
in tests.
2. Don't change the real `cwd` of the isolate during tests, as it affects
all tests, not just the current running test.
Fixes#8761
* 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.
Only implemented for Android devices for now. Compare the installed SHA1
to the latest build. If they match, there's no reason to reinstall the
build.
Fixes#8295
Do not attempt to deploy/debug wifi connected iOS devices. ios-deploy is
able to install over wifi, but we've had several bugs reporting failure
to run/debug once installation has completed when the device is also
connected via USB. Note that we don't currently support deploy/debug
over wifi since libimobiledevice (which is also required) requires a USB
connection.
* Teach flutter tools to find gradle
Flutter tools will now use Gradle from Android Studio, which is now found automatically.
flutter doctor will verify that Android Studio has been installed, and that the included Gradle is at least version 2.14.1.
It is still possible to manually configure the path to Android Studio (flutter config --android-studio-dir=XXX) or Gradle (flutter config --gradle-dir=XXX), but this should only be necessary if they're installed somewhere non-standard.
Only tested on Linux and macOS for now.
Fixes#8131
Artifacts are now located in a central place.
This will enable us to downlaod artifacts when we need them (instead of
downloading them all upfront).
This also makes replacing sky_snapshot with gen_snapshot easier.
