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.
Changed the default build output directory in the new project template
to build/, instead of android/build/ and android/app/build/.
Updated tools to ask the Gradle scripts what the build directory is,
since this is configurable in the build scripts, and we need to know
where the build output actually is.
Silenced output from 'flutter build aot' when invoked from Gradle, since
the output was confusing in this case.
Fixes#8723Fixes#8656Fixes#8138
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
- [x] Add custom logic on MacOS to determine if Java is installed before invoking `java`.
- [x] Check JAVA_HOME, platform specific logic, and finally PATH to locate the `java` executable.
- [x] Improved doctor messages.
Fixes#8508Fixes#8521
The gradle build scripts can be configured to output different
application IDs for different build types, so we need to examine the
built .apk to figure out the name of the package and activity.
Re-landing this change, updated to only get information from the .apk
if it exists.
Since the tools create an AndroidApk instance early, even before we've
actually built an .apk, we have to create a new instance after building,
so we can start the right app/activity.
Fixes#8327.
It's not just $HOME/.AndroidStudio2.2, it might also be
.AndroidStudioPreview2.3, or .AndroidStudioFooBar1.7, or whatever.
Made the Version parser less throw-happy, and relaxed the directory name
checks to allow for the above.
Fixes#8353.
If a target file is specified on the flutter tools command line, pass it
through to Gradle.
It is still possible to statically specify a target file in the flutter
section of build.gradle, but it is now possible to specify it on the
command line as well. The command line option takes precedence.
Fixes#8175.
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
* Fix bug parsing Gradle version.
Version from pub_semver requires versions of the format X.Y.Z. Gradle
doesn't follow semantic versioning, though, so version parsing would
fail on versions like '3.2'. Fixed by writing a custom Version class.
Also removed a check for apksigner when building Gradle-based projects.
Fixes#8298
* Remove SHA1 check from AndroidDevice.isAppInstalled()
The docs for isAppInstalled say 'check if a version of the given app is
already installed', however the current code returns true only if it's
the latest build that's installed.
This made sense in the past, when the use pattern was:
if (!isAppInstalled(...)) installApp(...);
but now the usage is:
if (isAppInstalled(...)) uninstallApp(...);
installApp(...);
This has the probably unintended consequence that if you run `flutter
install` or `flutter run` two times in a row with no source changes, the
second invocation will uninstall the app, but the first invocation might
not.
Removing the SHA1 check makes us always uninstall the app if it's
installed.
Fixes#8172
* 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
* Make new project template gradle-based for Android.
With this change, the 'new project' template uses the same gradle-based build for Android as the hello_services example. This has some implications on build performance, since we're now building a complete Android app instead of just combining a pre-compiled .dex with the Flutter assets.
The very first build is a little over 2x slower, since it needs to download gradle and build the build scripts before getting to the actual code. Subsequent builds with changes to the code are comparable to the old builds. Null builds are faster. Enabling the gradle daemon speeds up subsequent builds by around 5s.
* Move Flutter Gradle plugin to Flutter root.
If the tool is started immediately after a previous run of the tool, then
the most recent log timestamp may come from the previous run's logs.
The new instance of the tool should not print those logs.
This was happening during runs of the microbenchmark script.
* Update gradle example to support x86 in debug mode.
Changed the Flutter Gradle plugin a bit to better fit in with the
Android build.
Fixes#6136Fixes#6864Fixes#7539
This removes direct file access from within flutter_tools
in favor of using `package:file` via a `FileSystem` that's
accessed via the `ApplicationContext`.
This lays the groundwork for us to be able to easily swap
out the underlying file system when running Flutter tools,
which will be used to provide a record/replay file system,
analogous to what we have for process invocations.
This moves the various copies of port forwarding code in the Device subclasses into the ProtocolDiscovery class.
* move port forwarding to a common location
* throw exception if protocol Uri is not discovered or port forwarding fails
* cancel discovery protocol subscriptions on iOS launches (wasn't happening before)
* fix iOS port forwarding to match other implementations
* add tests
It is not enabled by default in the VM because applications not launched via the tools may try to connect with the debugger. This causes the debugger and the IDE to hang on Mac.
With this change, they're run via instance methods on an object
obtained through the context. This will allow us to substitute
that object in tests with replay/record versions to allow us to
mock out the os-layer in tests.
- [x] Stop unnecessarily building the flx a second time on startup.
- [x] Stop unncessarily copying the flx to the device a second time on startup.
- [x] Remove `startBundle` and move logic into `startApp`.
* Allow for application-specific log readers.
When running with prebuilt application binaries, those applications
aren't guaranteed to be named "Runner" (as it is when we build
the app locally in Flutter tools)
* convert pubGet to throw ToolExit on non-zero exit code
* convert commandValidator to throw ToolExit for non-zero exit code
* convert flutter commands to throw ToolExit for non-zero exit code
* use convenience method throwToolExit
* only show "if this problem persists" for unusual exceptions
When using --use-application-binary:
- [x] Stop flutter run from checking for a pubspec.yaml in current directory
- [x] Stop flutter run from invoking pub get
- [x] Set 'shouldBuild' based on --use-application-binary
- [x] Stop requiring 'lib/main.dart' to be present before running.
- [x] Stop building an FLX when launching on Android
* working on making a faster flutter run restart
* clean up todos; fire events on isolate changes
* use the Flutter.FrameworkInitialization event
* review comments
* iOS tools cleanup
1) Fix `flutter install` on both device and simulator to refer to the actual
bundle and not just the .generated folder
2) Fix `flutter run` on device to actually run vs just installing
Still TODO:
1) Discovered that isAppInstalled on iOS simulator always reports true,
meaning it'll never actually try to install the app.
Fixes#3947Fixes#1823
For developers with the platform tools installed but no SDK, it prevents
crashing in the flutter tool in favor of more user-friendly error messages
downstream.
