Remove devicelab specific code for shutting down gradle daemon, add --android-gradle-daemon option to build/run/drive`. Avoids need for un-tested devicelab specific handler. There are also some feature requests for this, so 2 birds one stone.
Example:
flutter build apk --no-android-gradle-daemon will pass --no-daemon on to gradle
Android Studio 4.1 moved the location of the .home file on Windows which is used to located the install directory. This functionality is important because it is how we locate and discover the Android SDK functionality, as well as the appropriate JRE.
fixes#67986
Work towards #39925
Currently flutter run will uninstall and reinstall if the initial install fails and the APK was previously installed. Allow drive to share this same logic by moving it into installApp and out of startApp.
This should reduce the occurrence of the error in the devicelab.
Cleans up some undocumented classes and re-organizes the AndroidDevices class to avoid the need for the static testing only member. Adds a script for tracking globals.
In cases where the Intellij/AS plugins are not located, display links to where they can be downloaded but do not surface an error. This should generally reduce confusion about whether the plugins are required for every installed IDE. For example, frequently users may only install AS so that they can install the Android SDK - or they may have multiple copies of Intellij installed.
For example: #66762
This changes the name of the generated output files on android in case a flavor with uppercase letters is used.
Previously, the lowercased flavor name would be used for the apk/aab file. Now, the flavor name is used as-is.
Avoid creating AndroidDevice discovery if the SDK cannot be located. Previously the tool would use which/where adb, however this required us to handle the AndroidSdk class being potentially null - which required an additional layer of indirection around all access. Sometimes these were forgotten leading to NPEs.
In general, not much can be done with an Android Device if the actual SDK is not installed.
Reland with fixed code + tests for null SDK + adb in AndroidDeviceDiscovery
Avoid creating AndroidDevice discovery if the SDK cannot be located. Previously the tool would use which/where adb, however this required us to handle the AndroidSdk class being potentially null - which required an additional layer of indirection around all access. Sometimes these were forgotten leading to NPEs.
In general, not much can be done with an Android Device if the actual SDK is not installed.
Attempt to simplify the Android SDK interface ahead of refactoring it. The locateAndroidSdk static method is called at startup to locate the android SDK, returning null if it cannot be found. These helper methods attempted to first look up the AndroidSDK if it was already null - which could only cover the case where someone installed the Android SDK while flutter was running (possibly through an IDE)
Add feature flags for android, ios, and fuchsia (on by default). After updating the g3 rollers, the fuchsia feature will be turned off by default. Creates a simpler base type of feature flags for g3 to extend.
Updates android, ios, fuchsia workflows to use feature flags check.
Removes concept of stable artifacts and checks on flutter version.
Fixes#58999#52859#12768
Remove unnecessary use of globals from base tests, and an android test. This changes the test to avoid bouncing through the global getters, which can lead to incorrectly cached zone values. Switches the memory filesystem implementation to the test implementation
instead of restricting profile/release mode based on whether the tool thinks the device is an emulator, restrict based on the device target architecture and the requested build mode. Notably, this enables release mode on x86_64 Android emulators, but not x86 emulators since we do not support that as an AOT target.
This does not add release mode support for simulators, since this requires us to build and upload artifacts for simulator/x86_64
The resident runner does not check if the ApplicationPackage is null when trying to stop the app. Update AndroidDevice.stopApp to handle this case by returning false.
The package will be null when flutter attach is used.
When the AndroidDevice checks for the current API version, it isn't handling a null response. While we can refuse to run on API levels that are unsupported, we should probably assume that a null response = lowest possible API level and allow these to run.
Previously the AdbLogReader did async setup in the StreamController.onListen callback, specifically it would query the api version and start the adb process. If the log subscription was cancelled before this setup completed, then the log output could (haven't confirmed) get added to a closed controller, causing the above state error.
* Update project.pbxproj files to say Flutter rather than Chromium
Also, the templates now have an empty organization so that we don't cause people to give their apps a Flutter copyright.
* Update the copyright notice checker to require a standard notice on all files
* Update copyrights on Dart files. (This was a mechanical commit.)
* Fix weird license headers on Dart files that deviate from our conventions; relicense Shrine.
Some were already marked "The Flutter Authors", not clear why. Their
dates have been normalized. Some were missing the blank line after the
license. Some were randomly different in trivial ways for no apparent
reason (e.g. missing the trailing period).
* Clean up the copyrights in non-Dart files. (Manual edits.)
Also, make sure templates don't have copyrights.
* Fix some more ORGANIZATIONNAMEs
...because otherwise, processes that think they're manipulating your
filesystem will be doing crazy things the test is ignoring, leading to
(at best) failures and (at worst) flakes or disk corruption.
We were using the `defaults` command-line utility to parse
Plist files, but it was never supported by Apple, and it
appears that in an upcoming OS release, it will be less likely
to work:
> WARNING: The defaults command will be changed in an upcoming
> major release to only operate on preferences domains. General
> plist manipulation utilities will be folded into a different
> command-line program.
Fixes https://github.com/flutter/flutter/issues/37701
`flutter build aar`
This new build command works just like `flutter build apk` or `flutter build appbundle`, but for plugin and module projects.
This PR also refactors how plugins are included in app or module projects. By building the plugins as AARs, the Android Gradle plugin is able to use Jetifier to translate support libraries into AndroidX libraries for all the plugin's native code. Thus, reducing the error rate when using AndroidX in apps.
This change also allows to build modules as AARs, so developers can take these artifacts and distribute them along with the native host app without the need of the Flutter tool. This is a requirement for add to app.
`flutter build aar` generates POM artifacts (XML files) which contain metadata about the native dependencies used by the plugin. This allows Gradle to resolve dependencies at the app level. The result of this new build command is a single build/outputs/repo, the local repository that contains all the generated AARs and POM files.
In a Flutter app project, this local repo is used by the Flutter Gradle plugin to resolve the plugin dependencies. In add to app case, the developer needs to configure the local repo and the dependency manually in `build.gradle`:
repositories {
maven {
url "<path-to-flutter-module>build/host/outputs/repo"
}
}
dependencies {
implementation("<package-name>:flutter_<build-mode>:1.0@aar") {
transitive = true
}
}
`flutter build aar`
This new build command works just like `flutter build apk` or `flutter build appbundle`, but for plugin and module projects.
This PR also refactors how plugins are included in app or module projects. By building the plugins as AARs, the Android Gradle plugin is able to use Jetifier to translate support libraries into AndroidX libraries for all the plugin's native code. Thus, reducing the error rate when using AndroidX in apps.
This change also allows to build modules as AARs, so developers can take these artifacts and distribute them along with the native host app without the need of the Flutter tool. This is a requirement for add to app.
`flutter build aar` generates POM artifacts (XML files) which contain metadata about the native dependencies used by the plugin. This allows Gradle to resolve dependencies at the app level. The result of this new build command is a single build/outputs/repo, the local repository that contains all the generated AARs and POM files.
In a Flutter app project, this local repo is used by the Flutter Gradle plugin to resolve the plugin dependencies. In add to app case, the developer needs to configure the local repo and the dependency manually in `build.gradle`:
repositories {
maven {
url "<path-to-flutter-module>build/host/outputs/repo"
}
}
dependencies {
implementation("<package-name>:flutter_<build-mode>:1.0@aar") {
transitive = true
}
}
