* Move web integration tool tests to web.shard
Web integration tool tests depend on DDC changes in SDK. This change
moves them to a separate shard and subshard so CI bot configurations
can run them separately.
In particular, with will allow running those tests on dart CI flutter
HHH web bot instead of a non-web one, allowing early detection and easy
classification of issues caused by SDK changes as VM- or Web related.
* Enabled verbose mode for flaky web_tool_tests
* Split out the test changes to be commited first
Necessary to work around #70013 (this looks like it will be fixed, but should protect us in the future)
Restores some notion of skipping pub, with differences from the prior implementation:
Off by default, and only used by the flutter command automatic pub get
A single check parameter. Uses the framework version cached per-project instead of a timestamp of the tool, to avoid cases where downloading a prebuilt framework would cause this check to no longer work.
* Remove references to dart:ui.Window, and point usages to PlatformDispatcher or SingletonFlutterWindow, as appropriate
* remove new test platform dispatchers
* Amend documentation
This reverts ae0a9cb560 and therefore relands #69629.
Additionally, `flutter update-packages --force-upgrade` has been run to update `pubspec.yaml` to resolve the analyze test failures.
Instead of loading the use-material-design asset data from a yaml file in the repo, leave it in dart code and simplify. Remove some of the globals, but not enough to update to testWithoutContext
initialize the flutter root as early as possible. This allows all interfaces to be normally injected into commands, even if those objects might read from the flutter root.
If no source files were changed by a hot reload, do not send the reload sources RPC. This slightly speeds up the no-op reloads and gives users a faster way to force a re-render.
* [flutter_tools] Support zipped application bundles for macOS
It is not possible to directly produce a directory (.app) in some build systems
but rather it must be zip'ed before being passed to the tool for
running. This adds support for attempting to extract an application
bundle from a zip file if the bundle is not already a directory. This
uses very similar code from lib/src/application_package.dart which is
used for extracting an ipa for iOS.
This introduces tests for the macos/application_package.dart behavior which did not exist before. These tests cover the changes in the PR and some of the existing behavior, but do not cover everything in that file.
The flutter run failures are cause by the application occasionally taking a long time to start up. This caused the ios fallback discovery to kick in, which will always fail if the application hasn't started. Solution: remove the iOS fallback discovery and wait up to 30 seconds.
This has not proven to reduce the flakes, but it does at least remove one error case and removes code that will no longer work without the mDNS fallback.
Currently we only have a test that measures if flutter drive can fail. Unfortunately it has been failing for multiple years based on the fact that the error is due to a missing Gradle config.
Add a smoke success test case, and update both tests to use the test API and the tester-device.
Moves the flutter root initialization to a static method on the cache. This is a small step towards making this functionality non-static and instead injected like normal members - however, completely removing all of the static-ness at once was too large of a change.
Instead document and add unit tests and change existing code as little as possible.
#47161
Rolls in several fixes to web tooling, including better handling of absolute file imports. Updates to latest vm service to unblock null safety mode query
Co-authored-by: Gary Roumanis <grouma@google.com>
Co-authored-by: Anna Gringauze <annagrin@google.com>
Performs some small cleanup on the hot reload code path.
- Combines nested try/catch into single try catch, update on clause now that package:vm_service is used and Map does not need to be caught.
- Cache FlutterViews for the lifetime of the hot reload method handler
- Set asset directory path once during startup and remove conditional set during hot reload
The tool observes a large number of unhandled exceptions during the file copy portion of flutter create. it is difficult to tell whether the permission issue is caused by the source/destination, or whether it is due to a bug in dart:io.
To work around this, implement a permission check for both the source and dest files. If either fails, the tool can exit with a more specific message.
If these checks pass, then perform the actual copy. If the copy fails, fallback to manually copying the bytes
Overhaul of flutter drive in order to deliver a better experience, namely:
* flutter run and flutter drive now share more flags, so code paths that were previously only testable on run are now testable on drive.
* Removes web-initialize-platform as this is no longer used
* flutter drive correctly sets up a logger that shows native exceptions, by connecting to the vm service.
* VM service connection now provides access to memory info without launching devtools (only for debug/profile mode)
Web changes
* Passes on the one test in the repo, otherwise the webdriver code has been isolated as much as possible
Additional NNBD related bug fixes:
No longer passes --enable-experiment to the test script. (FYI @blasten ). earlier we might have assumed that the flutter gallery benchmarks would be migrated along side the app and flutter driver, but only the app under test needs to be migrated. The test scripts should never be run with the experiment.
There have been some more additional reports of a missing 'package:characters' import after upgrading flutter. This has me concerned that our pub caching logic is incorrect. Instead of the tool attempting to guess when pub should be run, always delegate to pub.
Also takes an opportunity to fix the kernel snapshot depending on the .packages or package_config. Due to the generated: date field this causes extra rebuilds. Instead when pub get is run, write out an additional file with just the package contents and version.
Fixes#66777Fixes#65723
Overhaul of flutter drive in order to deliver a better experience, namely:
flutter run and flutter drive now share more flags, so code paths that were previously only testable on run are now testable on drive.
Removes web-initialize-platform as this is no longer used
flutter drive correctly sets up a logger that shows native exceptions, by connecting to the vm service.
VM service connection now provides access to memory info without launching devtools (only for debug/profile mode)
Web changes
Passes on the one test in the repo, otherwise the webdriver code has been isolated as much as possible
Additional NNBD related bug fixes:
No longer passes --enable-experiment to the test script. (FYI @blasten ). earlier we might have assumed that the flutter gallery benchmarks would be migrated along side the app and flutter driver, but only the app under test needs to be migrated. The test scripts should never be run with the experiment.
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>
