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.
