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
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
This PR suggests improving the IntelliJ plugin "jar" detection logic.
Previously:
The IntelliJ Flutter plugin was contained flutter-intellij.jar.
Currently:
It is named flutter-intellij-X.Y.Z.jar and does not contain META-INF/plugin.xml.
META-INF/plugin.xml is included in flutter-idea-X.Y.Z.jar.
So this PR changes the rules for searching the plugin's jar file.
Concretely, it looks for the jar file containing META-INF/plugin.xml in the plugin's package directory and reads the package version from its META-INF/plugin.xml.
Co-authored-by: Jonah Williams <jonahwilliams@google.com>
We'd like to see how many of these flakes are transient and how many involve the device/machine getting temporarily wedged. Add a retry with no delay to see if it is possible to add sufficient error handling to startApp/installApp to handle this.
Both start and stop app create an application package, but only start app used the application binary. Create the application package once and pass it to both start and stop app.
Do not allow attach in release mode, as there is not VM Service to connect to. Observed in crash reporting as thrown string which is changed to exception below.
This class is entirely superseded by the application package factory. Only drive and install use it, and removing it from drive will allow use-application-binary support.
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
All of the network requests from google cloud storage include an x-goog-hash header which contains an MD5 checksum. If present, use to validate that the downloaded binary is valid. This will rule out corrupt files as the cause of getting started crashers in the flutter_tool.
#38980
This does not fully resolve the above issue, because while we can check if the checksum matches what was expected from cloud storage, this A) may not necessarily be present and B) may not match up to what should be uploaded as part of the engine build process.
But when life gives you lemons you hash those lemons using an outdated hashing algorithm.
Reland of #67669
The flutter tool has a number of crashes on stable where an ArgumentError is thrown due to the process manager not being able to resolve an executable.
So that we can adjust/modify this logic, fold it into flutter and add some additional logging.
caches the resolved executable per target directory, to avoid repeated look ups.
Instead of throwing an argument error, attempts to run the executable as given if an exact path can't be found
Accept files or symlinks for the executable path.
user where/which to resolve path instead of package:process logic.
The flutter tool has a number of crashes on stable where an ArgumentError is thrown due to the process manager not being able to resolve an executable. Fold the resolution logic into the tool and use where/which instead of the package:process specific logic.
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.
This failure has been happening for a while but was covered by the overly broad catch. Removing that revealed that newer intellij versions have a different plugins file. The tool still can't find the file, but it won't crash now
Fixes#67918
For historical reasons, the flutter tool uploads dill files to paths based on the entrypoint URI. This isn't actually necessary, and the tool can use specific files : main.dart.incremental.dill for incremental dills, and main.dart.dill/main.dart.swap.dill for full dills. This allows hot restarting applications with an entrypoint outside of lib/ and simplifies the devFS code.
Fixes#63243
