This reverts commit 7cdc23b3e1bae2bc7bc2d1f34773eaa3629d4fcc.
The failure in the `native_assets_test` integration test on Windows was caused by the DevTools process not being shutdown by the `ColdRunner` when running the profile mode portion of the test. This resulted in the test being unable to clean up the project created by the test as DevTools was still holding onto a handle within the directory. This PR adds back the mistakenly removed DevTools shutdown logic in the `ColdRunner`.
1. Instead of getting the `FULL_PRODUCT_NAME` Xcode build setting (`Runner.app`) instead use `PRODUCT_NAME` since most places really want the product name, and the extension stripping wasn't correct when the name contained periods.
2. Don't instruct the user to open the `xcarchive` in Xcode if it doesn't exist.
Fixes https://github.com/flutter/flutter/issues/140212
Reverts: flutter/flutter#146593
Initiated by: zanderso
Reason for reverting: Consistently failing `Windows_android native_assets_android` as in https://ci.chromium.org/ui/p/flutter/builders/prod/Windows_android%20native_assets_android/2533/overview
Original PR Author: bkonyi
Reviewed By: {christopherfujino, kenzieschmoll}
This change reverts the following previous change:
This change is a major step towards moving away from shipping DDS via Pub.
The first component of this PR is the move away from importing package:dds to launch DDS. Instead, DDS is launched out of process using the `dart development-service` command shipped with the Dart SDK. This makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the removal of instances of DevTools being served manually by the flutter_tool, instead relying on DDS to serve DevTools. This will be consistent with how the standalone Dart VM serves DevTools, tying the DevTools lifecycle to a live DDS instance. This will allow for the removal of much of the logic needed to properly manage the lifecycle of the DevTools server in a future PR. Also, by serving DevTools from DDS, users will no longer need to forward a secondary port in remote workflows as DevTools will be available on the DDS port.
There's two remaining circumstances that will prevent us from removing DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory profiles
This PR also includes some refactoring around `DebuggingOptions` to reduce the number of debugging related arguments being passed as parameters adjacent to a `DebuggingOptions` instance.
This change is a major step towards moving away from shipping DDS via
Pub.
The first component of this PR is the move away from importing
package:dds to launch DDS. Instead, DDS is launched out of process using
the `dart development-service` command shipped with the Dart SDK. This
makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the
removal of instances of DevTools being served manually by the
flutter_tool, instead relying on DDS to serve DevTools. This will be
consistent with how the standalone Dart VM serves DevTools, tying the
DevTools lifecycle to a live DDS instance. This will allow for the
removal of much of the logic needed to properly manage the lifecycle of
the DevTools server in a future PR. Also, by serving DevTools from DDS,
users will no longer need to forward a secondary port in remote
workflows as DevTools will be available on the DDS port. This code is currently
commented out and will be enabled in a future PR.
There's two remaining circumstances that will prevent us from removing
DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory
profiles
This PR also includes some refactoring around `DebuggingOptions` to
reduce the number of debugging related arguments being passed as
parameters adjacent to a `DebuggingOptions` instance.
This PR adds initial support for Swift Package Manager (SPM). Users must opt in. Only compatible with Xcode 15+.
Fixes https://github.com/flutter/flutter/issues/146369.
## Included Features
This PR includes the following features:
* Enabling SPM via config
`flutter config --enable-swift-package-manager`
* Disabling SPM via config (will disable for all projects)
`flutter config --no-enable-swift-package-manager`
* Disabling SPM via pubspec.yaml (will disable for the specific project)
```
flutter:
disable-swift-package-manager: true
```
* Migrating existing apps to add SPM integration if using a Flutter plugin with a Package.swift
* Generates a Swift Package (named `FlutterGeneratedPluginSwiftPackage`) that handles Flutter SPM-compatible plugin dependencies. Generated package is added to the Xcode project.
* Error parsing of common errors that may occur due to using CocoaPods and Swift Package Manager together
* Tool will print warnings when using all Swift Package plugins and encourage you to remove CocoaPods
This PR also converts `integration_test` and `integration_test_macos` plugins to be both Swift Packages and CocoaPod Pods.
## How it Works
The Flutter CLI will generate a Swift Package called `FlutterGeneratedPluginSwiftPackage`, which will have local dependencies on all Swift Package compatible Flutter plugins.
The `FlutterGeneratedPluginSwiftPackage` package will be added to the Xcode project via altering of the `project.pbxproj`.
In addition, a "Pre-action" script will be added via altering of the `Runner.xcscheme`. This script will invoke the flutter tool to copy the Flutter/FlutterMacOS framework to the `BUILT_PRODUCTS_DIR` directory before the build starts. This is needed because plugins need to be linked to the Flutter framework and fortunately Swift Package Manager automatically uses `BUILT_PRODUCTS_DIR` as a framework search path.
CocoaPods will continue to run and be used to support non-Swift Package compatible Flutter plugins.
## Not Included Features
It does not include the following (will be added in future PRs):
* Create plugin template
* Create app template
* Add-to-App integration
Convert `ProjectMigration.run()` and `ProjectMigrator.migrate()` to be async.
Needed for Swift Package Manager migration, which requires some async processes: https://github.com/flutter/flutter/pull/146256
There are two issues in the previous implementation:
1. `_populateDevices` will return the devices from `deviceNotifier` if it had been initialized, assuming that once it's initialized, it has been properly populated. That assumption is not true because calling getters like `onAdded` would initialize `deviceNotifier` without populating it.
2. `deviceNotifier` instance might be replaced in some cases, causing `onAdded` subscribers to lose any future updates.
To fix (1), this commit added the `isPopulated` field in `deviceNotifier` as a more accurate flag to determine if we need to populate it.
To fix (2), this commit made `deviceNotifier` a final member in `PolingDeviceDiscovery`.
Explicitly handle the case where the iOS device is not paired. On `flutter run` show an error and bail instead of trying and failing to launch on the device.
On this PR:
```
$ flutter run -d 00008110-0009588C2651401E
'iPhone' is not paired. Open Xcode and trust this computer when prompted.
$
```
Fixes https://github.com/flutter/flutter/issues/144447
Closes https://github.com/flutter/flutter/pull/144095
Reland of https://github.com/flutter/flutter/pull/142709.
The revert of the revert is in the first commit, the fix in the commit on top.
The move of the fakes for packages/flutter_tools/test/general.shard/resident_runner_test.dart was erroneous before, as it was trying to use setters instead of a private field. This PR changes the private `_devFS` field in the fake to be a public `fakeDevFS` in line with other fakes.
## Original PR description
Native assets in other build systems are not built with `package:native_assets_builder` invoking `build.dart` scripts. Instead all packages have their own blaze rules. Therefore we'd like to not depend on `package:native_assets_builder` from flutter tools in g3 at all.
This PR aims to move the imports of `native_assets_builder` and `native_assets_cli` into the `isolated/` directory and into the files with a `main` function that are not used in with other build systems.
In order to be able to remove all imports in files used by other build systems, two new interfaces are added `HotRunnerNativeAssetsBuilder` and `TestCompilerNativeAssetsBuilder`. New parameters are then piped all the way through from the entry points:
* bin/fuchsia_tester.dart
* lib/executable.dart
The build_system/targets dir is already excluded in other build systems.
So, after this PR only the two above files and build_system/targets import from `isolated/native_assets/` and only `isolated/native_assets/` import `package:native_assets_cli` and `package:native_assets_builder`.
Context:
* https://github.com/flutter/flutter/issues/142041
Reverts flutter/flutter#142709
Initiated by: vashworth
Reason for reverting: `Mac tool_tests_general` started failing on this commit: https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20tool_tests_general/15552/overview
Original PR Author: dcharkes
Reviewed By: {christopherfujino, chingjun, reidbaker}
This change reverts the following previous change:
Original Description:
Native assets in other build systems are not built with `package:native_assets_builder` invoking `build.dart` scripts. Instead all packages have their own blaze rules. Therefore we'd like to not depend on `package:native_assets_builder` from flutter tools in g3 at all.
This PR aims to move the imports of `native_assets_builder` and `native_assets_cli` into the `isolated/` directory and into the files with a `main` function that are not used in with other build systems.
In order to be able to remove all imports in files used by other build systems, two new interfaces are added `HotRunnerNativeAssetsBuilder` and `TestCompilerNativeAssetsBuilder`. New parameters are then piped all the way through from the entry points:
* bin/fuchsia_tester.dart
* lib/executable.dart
The build_system/targets dir is already excluded in other build systems.
So, after this PR only the two above files and build_system/targets import from `isolated/native_assets/` and only `isolated/native_assets/` import `package:native_assets_cli` and `package:native_assets_builder`.
Context:
* https://github.com/flutter/flutter/issues/142041
Native assets in other build systems are not built with `package:native_assets_builder` invoking `build.dart` scripts. Instead all packages have their own blaze rules. Therefore we'd like to not depend on `package:native_assets_builder` from flutter tools in g3 at all.
This PR aims to move the imports of `native_assets_builder` and `native_assets_cli` into the `isolated/` directory and into the files with a `main` function that are not used in with other build systems.
In order to be able to remove all imports in files used by other build systems, two new interfaces are added `HotRunnerNativeAssetsBuilder` and `TestCompilerNativeAssetsBuilder`. New parameters are then piped all the way through from the entry points:
* bin/fuchsia_tester.dart
* lib/executable.dart
The build_system/targets dir is already excluded in other build systems.
So, after this PR only the two above files and build_system/targets import from `isolated/native_assets/` and only `isolated/native_assets/` import `package:native_assets_cli` and `package:native_assets_builder`.
Context:
* https://github.com/flutter/flutter/issues/142041
When the Dart VM is not found within 10 minutes in CI on CoreDevices (iOS 17+), stop the app and upload the logs from DerivedData. The app has to be stopped first since the logs are not put in DerivedData until it's stopped.
Also, rearranged some logic to have CoreDevice have its own function for Dart VM url discovery.
Debugging for https://github.com/flutter/flutter/issues/142448.
Part of work on [#101077](https://github.com/flutter/flutter/pull/141194). This is done as a separate PR to avoid a massive diff.
## Context
1. The `FakeCommand` class accepts a list of patterns that's used to match a command given to its `FakeProcessManager`. Since `FakeCommand` can match a list of patterns, not just specifically strings, it can be used to match commands where the exact value of some arguments can't (easily) known ahead of time. For example, a part of the tool may invoke a command with an argument that is the path of a temporarily file that has a randomly-generated basename.
2. The `FakeCommand` class provides on `onRun` parameter, which is a callback that is run when the `FakeProcessManager` runs a command that matches the `FakeCommand` in question.
## Issue
In the event that a `FakeCommand` is constructed using patterns, the test code can't know the exact values used for arguments in the command. This PR proposes changing the type of `onRun` from `VoidCallback?` to `void Function(List<String>)?`. When run, the value `List<String>` parameter will be the full command that the `FakeCommand` matched.
Example:
```dart
FakeCommand(
command: <Pattern>[
artifacts.getArtifactPath(Artifact.engineDartBinary),
'run',
'vector_graphics_compiler',
RegExp(r'--input=/.*\.temp'),
RegExp(r'--output=/.*\.temp'),
],
onRun: (List<String> command) {
final outputPath = (() {
// code to parse `--output` from `command`
})();
testFileSystem.file(outputPath).createSync(recursive: true);
},
)
```
Fixes https://github.com/flutter/flutter/issues/141827
Reland: https://dart-review.googlesource.com/c/sdk/+/346960 has rolled into g3, so the imports should now resolve in g3 as well.
> [!CAUTION]
> _Do NOT merge if "Google Testing" bot didn't run!_
Rolls the packages from https://github.com/dart-lang/native in the native assets implementation.
Most notable we're refactoring `package:native_assets_cli` for `build.dart` use.
Therefore, all imports to that package for Flutter/Dart should be to the implementation internals that are no longer visible for `build.dart` writers. Hence all the import updates.
No behavior in Flutter apps should change.
This PR also updates the template to use the latests version of `package:native_assets_cli` which no longer exposes all the implementation details.
Packages the native assets for iOS and MacOS in frameworks.
Issue:
* https://github.com/flutter/flutter/issues/140544
* https://github.com/flutter/flutter/issues/129757
## Details
* [x] This packages dylibs from the native assets feature in frameworks. It packages every dylib in a separate framework.
* [x] The dylib name is updated to use `@rpath` instead of `@executable_path`.
* [x] The dylibs for flutter-tester are no longer modified to change the install name. (Previously it was wrongly updating the install name to the location the dylib would have once deployed in an app.)
* [x] Use symlinking on MacOS.
Rolls the packages from https://github.com/dart-lang/native in the native assets implementation.
Most notable we're refactoring `package:native_assets_cli` for `build.dart` use.
Therefore, all imports to that package for Flutter/Dart should be to the implementation internals that are no longer visible for `build.dart` writers. Hence all the import updates.
No behavior in Flutter apps should change.
This PR also updates the template to use the latests version of `package:native_assets_cli` which no longer exposes all the implementation details.
I continued [my mission](https://github.com/flutter/flutter/pull/141431) to find as many typos as I could. This time it's a smaller set than before.
There is no need for issues since it's a typo fix.
Change the following in the `flutter create` templates. I didn't make any auto-migrations for existing apps because none seem that critical:
1. Turn on `ASSETCATALOG_COMPILER_GENERATE_SWIFT_ASSET_SYMBOL_EXTENSIONS` in iOS and macOS.
1. Turn on `BuildIndependentTargetsInParallel` in macOS template. https://github.com/flutter/flutter/pull/125827/files#r1181817619
1. Turn on `DEAD_CODE_STRIPPING` in macOS template.
1. Set `ENABLE_USER_SCRIPT_SANDBOXING=NO` in iOS and macOS template. `flutter` scripts don't work with this on. This might require a migration in the future to explicitly turn this one off. However at least for now if the setting isn't present it defaults to `NO`.
Add migration for `LastUpgradeVersion` so users won't see these validation issues in Xcode.
Run migrator on all the example apps. A few aren't Flutter apps so I edited them in Xcode.
Fixes https://github.com/flutter/flutter/issues/140253
See also https://github.com/flutter/flutter/issues/125817 and https://github.com/flutter/flutter/pull/90304.
Fixes https://github.com/flutter/flutter/issues/139709
This adds a static helper method `ProcessUtils.writelnToStdinGuarded()`, which will asynchronously write to a sub-process's STDIN `IOSink` and catch errors.
In talking with Brian, it sounds like this is the best and most reliable way to catch `SocketException`s during these writes *to sub-process file descriptors* specifically (with a "real" hard drive file, the future returned by `.flush()` should complete with the write error).
Also, as I note in the dartdoc to `writelnToStdinGuarded()`, the behavior seems to be different between macOS and linux.
Moving forward, in any place where we want to catch exceptions writing to STDIN, we will want to use this new helper.
For CoreDevices we use a combination of mDNS and device logs to find the Dart VM url. If mDNS fails first, it will cause the launch to fail even though the device logs may be able to find the url. So if one of the methods fails, wait for the other method before failing the launch.
Fixes https://github.com/flutter/flutter/issues/139685.
Relates to tracker issue:
- https://github.com/flutter/flutter/issues/128251
This PR includes 3 major updates:
- Adding the `commandHasTerminal` parameter for `Event.flutterCommandResult`
- In `packages/flutter_tools/lib/src/runner/flutter_command.dart`
- Adding the new event for `sendException` from package:usage to be `Event.exception` (this event can be used by all dash tools)
- In `packages/flutter_tools/lib/runner.dart`
- Migrating the generic `UsageEvent` which was only used for Apple related workflows for iOS and macOS. I did an initial analysis in this [sheet](https://docs.google.com/spreadsheets/d/11KJLkHXFpECMX7tw-trNkYSr5MHDG15XNGv6TgLjfQs/edit?resourcekey=0-j4qdvsOEEg3wQW79YlY1-g#gid=0) to identify all the call sites
- Found in several files, highlighted in the sheet above
This implements https://github.com/flutter/flutter/issues/132654#issuecomment-1738221257, namely:
Make `Chromium.close` more robust:
* Send `SIGTERM` and wait up to 5 seconds, if the process exited, great! Return from the function.
* If the process has not exited, then send a `SIGKILL`, which is a much firmer way to exit a process. Same as before, wait up to 5 seconds, if the process exited, great! Return from the function.
* If it still hasn't exited then give up trying to exit Chromium, just print a warning to the console and return from the function.
Bonus: a few nullability fixes and extra `-v` logging.
Fixes https://github.com/flutter/flutter/issues/132654
Support for FFI calls with `@Native external` functions through Native assets on Windows. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for Windows.
Mainly follows the design of https://github.com/flutter/flutter/pull/134031.
Specifically for Windows in this PR is the logic for finding the compiler `cl.exe` and environment variables that contain the paths to the Windows headers `vcvars.bat` based on `vswhere.exe`.
So there appears to be a race situation between the flutter CLI and Xcode. In the CLI, we update the `CONFIGURATION_BUILD_DIR` in the Xcode build settings and then tell Xcode to install, launch, and debug the app. When Xcode installs the app, it should use the `CONFIGURATION_BUILD_DIR` to find the bundle. However, it appears that sometimes Xcode hasn't processed the change to the build settings before the install happens, which causes it to not be able to find the bundle.
Fixes https://github.com/flutter/flutter/issues/135442
---
Since it's a timing issue, there's not really a consistent way to test it.
I was able to confirm that it works, though, by using the following steps:
1. Create a flutter project
2. Open the project in Xcode
3. `flutter clean`
4. `flutter run --profile -v`
If I saw a print line `stderr: CONFIGURATION_BUILD_DIR: build/Debug-iphoneos`, that means it first found the old and incorrect `CONFIGURATION_BUILD_DIR` before updating to the the new, so I was able to confirm that it would wait until it updated.
Xcode uses the CONFIGURATION_BUILD_DIR build setting to determine the location of the bundle to build and install. When launching an app via Xcode with the Xcode debug workflow (for iOS 17 physical devices), temporarily set the CONFIGURATION_BUILD_DIR to the location of the bundle so Xcode can find it.
Also, added a Xcode Debug version of the `microbenchmarks_ios` integration test since it uses `flutter run --profile` without using `--use-application-binary`.
Fixes https://github.com/flutter/flutter/issues/134186.
