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 f4a13bc72b0d0a6f08592a24a61cc92f86e62061.
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.
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.
On flutter run, we update ios/Flutter/Generated.xcconfig with various
Flutter-specific settings required by xcode_backend.sh during a build
from Xcode. These settings need to be present at the time the project is
loaded since Xcode doesn't pick up live updates to these files.
Without these settings, Xcode fails to locate xcode_backend.sh itself,
causing the build to fail until the Xcode project has been closed and
re-opened. This also prevents Xcode's project updater from 'helpfully'
suggesting to clean up and delete the Generated.xcconfig file.
* 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.
