While exploring https://github.com/flutter/flutter/issues/107607, I noticed that flutter_tools test results change based on whether `dart test` is run from a terminal or from a process (such as a Dart program). I also ran into this while writing tests for https://github.com/flutter/flutter/pull/150667.
This is due to tests that rely on the global `Stdio` instance, on which the `hasTerminal` property depends on whether the tool is being invoked from a terminal.
Ideally, `testUsingContext` would require any tests that depend on `globals.stdio` to define an override for `Stdio`, but this is not the case. Until a solution to this more general problem is figured out, I think we should have `testUsingContext` always provide a `Stdio` override by default.
The current URL has 2 /to, but it should only be 1. However, this url redirects to https://docs.flutter.dev/release/breaking-changes/android-java-gradle-migration-guide, so I can change it to that if it's preferred just to go to the final destination - just don't know if it's a redirect for a reason
i didn't create an issue as it's a doc change, but if that's a requirement I can do that
This PR changes the project name logic for `flutter create` to look for the name in the pubspec.yaml `name` field,
before falling back to the directory name.
Fixes https://github.com/flutter/flutter/issues/53106
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
https://github.com/flutter/flutter/pull/150645 tries to shut down Chrome by sending a browser close command through a debug protocol. The webkit_inspection_protocol library used to send the command may throw a SocketException if Chrome has already been shut down.
This changes the mapping for the Dart SDK inside Flutter from `org-dartlang-sdk:///third_party/dart/sdk` to org-dartlang-sdk:///flutter/third_party/dart/sdk`. This URI changed in https://github.com/flutter/engine/pull/51917 but was not caught by tests because they only tested a specific set of mappings and there were no integration tests checking what URIs were actually produced by a running app.
So, this change also adds an integration tests that ensures that a real running app produces URIs that are then correctly mapped.
Fixes https://github.com/Dart-Code/Dart-Code/issues/5164.
Reverts: flutter/flutter#150969
Initiated by: goderbauer
Reason for reverting: Failing test in https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8743574743030691569/+/u/run_android_obfuscate_test/stdout
Original PR Author: gmackall
Reviewed By: {christopherfujino, reidbaker}
This change reverts the following previous change:
After the land of https://github.com/flutter/engine/pull/53592, there is some log spam:
```
e: /Users/mackall/.gradle/caches/transforms-3/c1e137371ec1afe9bc9bd7b05823752d/transformed/fragment-1.7.1/jars/classes.jar!/META-INF/fragment_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /Users/mackall/.gradle/caches/transforms-3/d86c7cb1c556fe1655fa56db671c649c/transformed/jetified-activity-1.8.1/jars/classes.jar!/META-INF/activity_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
...
```
I think this is harmless, but still annoying. Upgrading the AGP version fixes it. To be honest, I don't know why (I expected the Kotlin version would do it). But after https://github.com/flutter/flutter/pull/146307, our tests have been running on AGP/Gradle 8.1/8.3 for a while, so it makes sense to upgrade anyways.
In a follow up PR:
1. Also upgrade the tests that were left behind in https://github.com/flutter/flutter/pull/146307, as I think removal of discontinued plugins paved the way here.
After the land of https://github.com/flutter/engine/pull/53592, there is some log spam:
```
e: /Users/mackall/.gradle/caches/transforms-3/c1e137371ec1afe9bc9bd7b05823752d/transformed/fragment-1.7.1/jars/classes.jar!/META-INF/fragment_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /Users/mackall/.gradle/caches/transforms-3/d86c7cb1c556fe1655fa56db671c649c/transformed/jetified-activity-1.8.1/jars/classes.jar!/META-INF/activity_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
...
```
I think this is harmless, but still annoying. Upgrading the AGP version fixes it. To be honest, I don't know why (I expected the Kotlin version would do it). But after https://github.com/flutter/flutter/pull/146307, our tests have been running on AGP/Gradle 8.1/8.3 for a while, so it makes sense to upgrade anyways.
In a follow up PR:
1. Also upgrade the tests that were left behind in https://github.com/flutter/flutter/pull/146307, as I think removal of discontinued plugins paved the way here.
The Gradle Kotlin DSL also allows for type-safe application of the Flutter Gradle plugin, which is currently undetected by the CLI
```kotlin
plugins {
dev.flutter.`flutter-gradle-plugin`
}
```
Please note that the added test case isn't ideal, since the example gradle isn't actually valid kotlin DSL, however the `kotlin host app language with Gradle Kotlin DSL` is identical
Fixes#149859
If the user specifies the `--no-web-resources-cdn` or `--local-web-sdk`, we should use the local version of CanvasKit. `flutter.js` now has a flag that can be specified in the build configuration that tells it to load locally instead.
Also, added a link to the relevant docs in the web template warnings.
This addresses https://github.com/flutter/flutter/issues/148713
Also fixes https://github.com/flutter/flutter/issues/145559
Work towards https://github.com/flutter/flutter/issues/132712.
After this PR, after a completed `flutter build apk` command, we:
- Emit a `manifest-impeller-disabled` command if `io.flutter.embedding.android.EnableImpeller` is `'false'`.
- Emit a `manifest-impeller-disabled` command if `io.flutter.embedding.android.EnableImpeller` is _missing_.
- Emit a `manifest-impeller-enabled` command if `io.flutter.embedding.android.EnableImpeller` is `'true'`.
We will need to change the default (see `_impellerEnabledByDefault` in `project.dart`) before releasing, otherwise we will misreport `manifest-impeller-disabled` at a much higher rate than actual. If there is a way to instead compute the default instead of hard-coding, that would have been good.
See <https://docs.flutter.dev/perf/impeller#android> for details on the key-value pair.
---
I also did a tad of TLC, by removing the (now-defunct) `Usage` events for `flutter build ios`, so they are consistent.
/cc @zanderso, @chinmaygarde, @jonahwilliams
The previous approach of killing the Chromium parent process sometimes caused leaks of child processes on Windows. The Browser.close command in the debug protocol will tell Chromium to shut down all of its processes.
Two issues I noticed when I hit the issue at https://github.com/flutter/flutter/issues/149258
1. When the an app.stop event arrives from Flutter with an error, DAP does not pass that error back to the client so there's no visibility of the error.
2. If app.stop occurs but no app.start ever did, we leave the progress notification hanging around
This fixes both by handling app.stop and closing any open launch progress as well as passing any error to the client.
Fixes https://github.com/Dart-Code/Dart-Code/issues/5124
Even though this does not fix the below issue lets land this anyway as not logging to stderr when clearing logs makes sense to me.
related https://github.com/flutter/flutter/issues/150093
The test added is bad. It does not verify the behavior changed.
To verify the behavior changed correctly I would need to modify the generic device class to have clearLogs be an async function like many of the other calls. That would mean modifying every other device type and their implementations and their tests. Then I would need to update android_device to expose its logger. That is more than I have time for to validate a 2% flake error.
Feel free to disagree in the comments on this pr.
PR to pave the way for https://github.com/flutter/engine/pull/53001 to re-land
Summary:
- Enforces use of Kotlin >= `1.7.0` (please see below note)
- Fixes ci failures that prevented the above PR from landing.
Details:
Because it landed initially, we are able to fake the roll in this PR to fix all the tests ([see my comment](https://github.com/flutter/flutter/pull/149204#discussion_r1617924772)).
Fixes all the tests that failed:
1. `module_test` failing on multiple platforms (3/9 of the failures).
Failure is
```
> Android resource linking failed
ERROR:/b/s/w/ir/x/t/flutter_module_test.KECMXW/hello/.android/plugins_build_output/device_info/intermediates/merged_res/release/values/values.xml:194: AAPT: error: resource android:attr/lStar not found.
```
This is a rather unhelpful error message but some [folks online suggest](https://stackoverflow.com/a/69050529) that upgrading your `compileSdk` version fixes this.
These resolve when I remove the dependency on the long discontinued [package_info](https://pub.dev/packages/package_info) and [device_info](https://pub.dev/packages/device_info) packages, perhaps because they are transitively pulling in low `compileSdk` versions? This is unclear to me.
2. `module_custom_host_app_name_test` was failing for the same reason (another 3/9, or cumulative 6/9).
3. `tool_integration_tests_3_4` was a flake ð (7/9)
4. `framework_tests_slow` needed a newer version of the Kotlin Gradle plugin (the flutter tool tells us this, so I just upgraded as suggested) and it resolved (8/9)
5.`android_preview_tool_integration_tests` needed newer AGP and KGP versions. I also refactored the tests, and bumped our error versions, fixing https://github.com/flutter/flutter/issues/142653.
**Note that the bump to KGP is not in line with our policy** - we didn't warn for `1.5.0-1.6.x` for a release (or at all) before dropping support. But I think it might still be justified:
- The bump to our androidx libraries unblocks ongoing Scribe work, and also includes a fix for a [memory leak](https://github.com/flutter/flutter/issues/129307#issuecomment-1601636959) and a [crash on folding phones](https://github.com/flutter/flutter/issues/114868#issuecomment-2133226962), among many other bug fixes.
- Gradle [doesn't test on half of that range](https://docs.gradle.org/current/userguide/compatibility.html#kotlin), and so we implicitly can't claim to support it either. More generally, our Java and Kotlin support ranges should probably strictly fall within what Gradle tests.
This adds the 'fail-fast' argument to flutter test, since dart test already supports this feature. Tests can now be stopped after first failure.
Fixes#124406
Fixes https://github.com/flutter/flutter/issues/145158.
In an ideal world, the `--machine` flag would be strictly a global flag which sub-commands can choose to use (or perhaps just to report a `toolExit` that they don't have a `--machine` supported-mode if not. However currently, there is both a global flag, and command-specific flags.
This leads to the confusing scenario where:
```sh
flutter devices --machine
```
... still checks for a Flutter update, printing a banner and breaking the JSON output.
This PR "fixes" that by allowing `--machine` _anywhere_ in the command-line arguments to suppress the check.
/cc @johnmccutchan.
Currently, the error message displayed to regenerate the lockfiles gives a Unix-like command ./gradlew, which will be incorrect for Windows environments. This PR uses globals.platform.isWindows to give the appropriate command.
closes#136763
- When `--web-renderer` is omitted, keep the value `null` until it later materializes to either `canvaskit` or `skwasm`.
- No more hardcoded defaults anywhere. We use `WebRendererMode.defaultForJs/defaultForWasm` instead.
- When in `--wasm` mode, the JS fallback is now `canvaskit` instead of `auto`.
- Add test for defaulting to `skwasm` when `--wasm` is enabled.
Fixes https://github.com/flutter/flutter/issues/149826
If the service is disposed when we make calls on it, we need to bubble up an exception that is understood by the callers.
This is another speculative fix for https://github.com/flutter/flutter/issues/149238.
Fixes https://github.com/flutter/flutter/issues/149386. Fixes https://github.com/flutter/flutter/issues/106150.
The stocks test app includes Dart files containing localized messages generated by `package:flutter_localizations`. However, these files appear to have become out of date. Running `pub get` in the project will regenerate these files and generate a diff, which can be annoying when working on the repo.
This PR generates the files. ~~It also updates the templates for these files to be compliant with flutter/flutter repo lint rules, including `noop_primitive_operations` and `use_super_parameters`.~~ It also adds `// ignore_for_file: type=lint` to these files to disable linting for these files. This avoids issues like https://github.com/flutter/flutter/issues/106150 and [this](https://github.com/flutter/flutter/pull/148741#issuecomment-2141161753).
Dart2wasm only needs a platform file, which contains the compiled
`dart:*` libraries. There's no need to specify a seperate `--dart-sdk`
option (anymore).
(See also https://dart-review.googlesource.com/c/sdk/+/366821)
This PR modifies the `flutter create --empty` command to not delete the `test/` folder when run on an existing app project.
Before:
```bash
flutter create my_app --empty
mkdir my_app/test
if test -d my_app/test; then echo "test exists"; else echo "test does not exist"; fi # test exists
flutter create my_app --empty
if test -d my_app/test; then echo "test exists"; else echo "test does not exist"; fi # test does not exist
```
After:
```bash
flutter create my_app --empty
mkdir my_app/test
if test -d my_app/test; then echo "test exists"; else echo "test does not exist"; fi # test exists
flutter create my_app --empty
if test -d my_app/test; then echo "test exists"; else echo "test does not exist"; fi # test exists
```
Fixes https://github.com/flutter/flutter/issues/134928
This PR adds support invoking `link.dart` hooks.
Link hooks can add new assets. Link hooks can transform assets sent to link hook from build hooks.
This PR does not yet add support for getting tree-shake information in the link hooks. This is pending on defining the `resources.json` format (https://github.com/dart-lang/sdk/issues/55494).
Issue:
* https://github.com/flutter/flutter/issues/146263
## Implementation considerations
The build hooks could be run before Dart compilation and the link hooks after Dart compilation. (This is how it's done in Dart standalone.) However, due to the way the `Target`s are set up, this would require two targets and serializing and deserializing the `BuildResult` in between these. This would lead to more code but no benefits. Currently there is nothing that mandates running build hooks before Dart compilation.
## Testing
* The unit tests verify that the native_assets_builder `link` and `linkDryRun` would be invoked with help of the existing fake.
* The native assets integration test now also invokes an FFI call of a package that adds the asset during the link hook instead of the build hook.
* In order to keep coverage of the `flutter create --template=package_ffi`, `flutter create` is still run and the extra dependency is added and an extra ffi call is added. (Open to alternative suggestions.)
This PR adds a new flag `default-flavor` in the `flutter` section of `pubspec.yaml`. It allows developers of multi-flavor android apps to specify a default flavor to be used for `flutter run`, `flutter build` etc.
Using `flutter run` on flavored apps already works without specifying `--flavor` already works on iOS (it defaults to the `runner` schema), so I (and others in #22856) figured this would be nice to have.
fixes#22856
Fixes https://github.com/flutter/flutter/issues/148354
Fixes https://github.com/flutter/flutter/issues/147142
Closes https://github.com/flutter/flutter/pull/147144
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
`'flutter create should tool exit if the template manifest cannot be read'` fails consistently, as shown by #148614.
The test expects a `ToolExit` with the message "Unable to read the template manifest", but depending on how the test is being run, a different exception ("Cannot create a project within the Flutter SDK") is sometimes thrown first.
This pull request relocates the test project to `dev/` to prevent the extraneous error.
Adds an empty privacy manifest, and commented out code to include it in the build, to the plugin template. This will make it much easier to explain how to add a privacy manifest in plugin docs, since instead of explaining the format of the file from scratch and providing example code to inculde it, we can just instruct people to add entries to an exisitng file and then uncomment a line or two. This will also make it much easier to figure out from the template output itself how to add support for people who don't find the documentation.
Part of https://github.com/flutter/flutter/issues/131940
Fixes https://github.com/flutter/flutter/issues/140013
DDS was temporarily pinned to 4.1.0 because 4.2.0 triggered some test
failures (see https://github.com/flutter/flutter/pull/147250). Those
failures should be fixed by vm_service 14.2.2, so this unpins DDS and
rolls both of these packages (along with devtools_shared, which is a DDS
dependency).
(If the bot updates vm_service before this is done, I can rebase over
that will reduce the size of this PR to just a few files)
### Some background:
* Flutter registers the hot-restart service extension for all devices **except** web devices. For web devices, DWDS registers the service extensions.
* When a user is debugging their code via VS Code, the VS Code Dart extension [sends a hot-restart](94cb81c552/src/debug/run_daemon_base.ts (L100)) request via stdin/out to flutter_tools
* flutter_tools then [calls the "hotRestart" service extension](f3978c7a46/packages/flutter_tools/lib/src/isolated/resident_web_runner.dart (L447)) (which, again, has been registered by DWDS)
### Why is this change necessary?
In DWDS, we are changing how we register the "hotRestart" service extension (here is the PR for that: https://github.com/dart-lang/webdev/pull/2388). Previously, we registered the "hotRestart" service extension on a client that was directly connected to the VmService. With https://github.com/dart-lang/webdev/pull/2388, we will be registering the "hotRestart" service extension on a client that is connected to DDS.
When a service extension is registered against DDS, DDS adds a prefix to the service extension method name (e.g. "hotRestart" becomes "s0.hotRestart"). It informs clients of the service extension name via `kServiceRegistered` events sent to the `Service` stream.
Therefore, this change simply listens to those service extension registered events, and uses them to determine the "hotRestart" service extension's method name.
Part of #137040 and #80374
- Extracted getting plugin implementation candidates and the default implementation to its own method
- Extracted resolving the plugin implementation to its own method
- Simplify candidate selection algorithm
- Support overriding inline dart implementation for an app-facing plugin
- Throw error, if a federated plugin implements an app-facing plugin, but also references a default implementation
- Throw error, if a plugin provides an inline implementation, but also references a default implementation
Fix dependency tracking in the build.
* https://github.com/flutter/flutter/issues/147643
## Testing
It's not clear to me where to test the caching behavior of specific targets.
* test/general.shard/build_system/targets/common_test.dart
* This doesn't test the caching behavior of any targets
* test/general.shard/build_system/build_system_test.dart
* test/general.shard/cache_test.dart
* Both of these don't test specific `Target`s, these have `TestTarget`s.
* test/integration.shard/isolated/native_assets_test.dart
* This could work, but it's an integration test that already takes long to run.
This PR resolves#147806
- List plugin that want to be compiled against a higher Android SDK version
- List plugins that depend on a different NDK version (we don't have a way to compare them)
- Small formatting and wording improvements
- Update syntax to work for both Groovy and Kotlin
- If project uses `build.gradle.kts`, then it is mentioned in the warning message (previously always `build.gradle` was mentioned)
<img width="1209" alt="demo" src="https://github.com/flutter/flutter/assets/40357511/be3522b5-d1b4-4983-9fed-8aaa0f0bc7f7">
This pull request aims for improved readability, based on issue #146600.
```dart
// before
List<SupportedPlatform> getSupportedPlatforms({bool includeRoot = false}) {
final List<SupportedPlatform> platforms = includeRoot
? <SupportedPlatform>[SupportedPlatform.root]
: <SupportedPlatform>[];
if (android.existsSync()) {
platforms.add(SupportedPlatform.android);
}
if (ios.exists) {
platforms.add(SupportedPlatform.ios);
}
if (web.existsSync()) {
platforms.add(SupportedPlatform.web);
}
if (macos.existsSync()) {
platforms.add(SupportedPlatform.macos);
}
if (linux.existsSync()) {
platforms.add(SupportedPlatform.linux);
}
if (windows.existsSync()) {
platforms.add(SupportedPlatform.windows);
}
if (fuchsia.existsSync()) {
platforms.add(SupportedPlatform.fuchsia);
}
return platforms;
}
// after
List<SupportedPlatform> getSupportedPlatforms({bool includeRoot = false}) {
return <SupportedPlatform>[
if (includeRoot) SupportedPlatform.root,
if (android.existsSync()) SupportedPlatform.android,
if (ios.exists) SupportedPlatform.ios,
if (web.existsSync()) SupportedPlatform.web,
if (macos.existsSync()) SupportedPlatform.macos,
if (linux.existsSync()) SupportedPlatform.linux,
if (windows.existsSync()) SupportedPlatform.windows,
if (fuchsia.existsSync()) SupportedPlatform.fuchsia,
];
}
```
In service of https://github.com/flutter/flutter/issues/146879 and https://github.com/flutter/flutter/issues/145812. In these issues, we see what appears to be the flutter tool getting stuck somewhere during hot reload. It may help if we knew were exactly where we are getting stuck (preparing assets, writing them to device, etc.).
This PR adds a new parameter to `FlutterTestDriver::run`, `verbose`. When verbose is set, `FlutterTestDriver` will run `flutter` with `--verbose` in its tests. Keep in mind that `FlutterTestDriver` only prints logs from `flutter` when a test fails, so this shouldn't spam the logs of passing tests.
This PR sets the parameter when invoking the flaky tests from https://github.com/flutter/flutter/issues/146879 and #145812, so we should see more detailed logs in future flakes.
While this is a low risk PR, you can verify the change by intentionally breaking hot reload code, clearing the cached tool binaries, and then running either of these tests.
## Description
This introduces a list of packages that we will explicitly not pin. It is to be used for things where the package isn't actually published, but is a transitive dependency of another package included in the SDK. This happens with the `macros` package, for instance, which depends on the private, unpublished, `_macros` package where the SDK does some tricky things to depend on it (it depends on "any", but ships it as part of the SDK).
Also ran `flutter update-packages --force-update` to update all of the pubspec files.
## Related Issues
- Fixes#147656
## Tests
- Added a test that makes sure that explicitly unpinned packages don't show up in the pinned list.
- added language for all code blocks
- replaced `bash` or `shell` with `sh` for consistency.
- added `sh` and `console` in the GitHub template link generator.
- updated test for GitHub template.
Uses kernel concatenation to concatenate the `program.dill` and `native_assets.dill`.
This will enable compiling `native_assets.dill` after `program.dill` so that tree-shaking information can be used.
Issue:
* https://github.com/flutter/flutter/issues/146270
## Implementation choices
* We can either run the frontend_server twice as a process invocation (current PR), or keep the process running after the dart compilation and then shut it down after native assets compilation to kernel. Keeping the process running would require more coordination between different `Target`s.
* We can either chose to only do separate kernel file compilation in release (AOT) builds, or do it both for JIT and AOT (current PR). Doing it differently in JIT/AOT means more conditionals in lib/src/build_system/targets/, doing it single-shot in JIT might be more performant though.
Update: Both of these are mitigated by not running the kernel compiler process if there are no native assets at all.
## Implementation notes
This only updates `flutter assemble`.
The kernel compilation calls in `flutter run` do not require kernel concatenation. The native-assets-kernel-mapping in `flutter run` contains results from `--dry-run` invocations of `hook/build.dart` (and in the future `hook/link.dart`). These `--dry-run` invocations do not get access to tree-shaking information, so the `link` hook to be introduced later can be run before Dart compilation.
## Tests
* Updated the `Target`s tests to reflect the new implementation.
## Related CLs
* frontend_server support: https://dart-review.googlesource.com/c/sdk/+/363567
* Same PR for Dart standalone: https://dart-review.googlesource.com/c/sdk/+/362384
When Swift Package Manager feature is enabled, create app and create plugin will have Swift Package Manager integration already added and will not need to undergo a migration.
Fixes https://github.com/flutter/flutter/issues/146371.
```
flutter config --enable-swift-package-manager
flutter create --ios-language swift --platforms ios,macos swift_app_name
flutter create --ios-language objc --platforms ios objc_app_name
flutter create --template=plugin --ios-language swift --platforms ios,macos swift_plugin_name
flutter create --template=plugin --ios-language objc --platforms ios objc_plugin_name
```
Here's another PR with a couple of typos fixed. As you can see there was a typo in _fileReferenceI**n**dentifiers_, in class _ParsedProjectInfo._ Maybe we should do some check on that since I'm not sure if that property is used somewhere outside Flutter?
From https://github.com/flutter/flutter/issues/143348#issuecomment-2016047148:
> before we ship, we should add a printTrace to the tool about each asset transformer we're invoking and the path/arguments we called it with
I think this is a good idea since asset transformers can be arbitrary Dart programsâmeaning that a lot can go wrong when running them. For example, they can hang indefinitely or perform some sort of I/O that later results in a tool crash. Knowing that asset transformation was involved when debugging a crash (or a slow/stuck `flutter build`) could be useful, so I think adding a `printTrace` or two is a good idea (or at least not a bad one).
This PR will opt out users from legacy analytics if they have already been opted out from package:unified_analytics.
After successfully merging into main, this will be CP'd into beta and stable channels
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
Changing the web renderer doesn't directly modify the environment's dart defines, and so doesn't do a full build invalidation. We need to include the web renderer in the build key for the compiler configuration. This information is used directly by the web targets to modify the dart defines that are passed into the compiler, so we need to rebuild if this information changes.
When performing artifact lookups for `Artifact.genSnapshot` for macOS desktop builds, a `TargetPlatform` is used to determine the name of the tool, typically `gen_snapshot_$TARGET_ARCH`. Formerly, this tool was always named `gen_snapshot`.
The astute reader may ask "but Chris, didn't we support TWO target architectures on iOS and therefore need TWO `gen_snapshot` binaries?" Yes, we did support both armv7 and arm64 target architectures on iOS. But no, we didn't initially have two `gen_snapshot` binaries. We did *build* two `gen_snapshots`:
* A 32-bit x86 binary that emitted armv7 AOT code
* A 64-bit x64 binary that emitted arm64 AOT code
At the time, the bitness of the `gen_snapshot` tool needed to match the bitness of the target architecture, and to avoid having to do a lot of work plumbing through suffixed `gen_snapshot` names, the author of that work (who, as evidenced by this patch, is still paying for his code crimes) elected to "cleverly" lipo the two together into a single multi-architecture macOS binary still named `gen_snapshot`. See: https://github.com/flutter/engine/pull/4948
This was later remediated over the course of several patches, including:
* https://github.com/flutter/engine/pull/10430
* https://github.com/flutter/engine/pull/22818
* https://github.com/flutter/flutter/pull/37445
However, there were still cases (notably `--local-engine` workflows in the tool) where we weren't computing the target platform and thus referenced the generic `gen_snapshot` tool.
See: https://github.com/flutter/flutter/issues/38933
Fixed in: https://github.com/flutter/engine/pull/28345
The test removed in this PR, which ensured that null `SnapshotType.platform` was supported was introduced in https://github.com/flutter/flutter/pull/11924 as a followup to https://github.com/flutter/flutter/pull/11820 when the snapshotting logic was originally extracted to the `GenSnapshot` class, and most invocations still passed a null target platform.
Since there are no longer any cases where `TargetPlatform` isn't passed when looking up `Artifact.genSnapshot`, we can safely make the platform non-nullable and remove the test.
This is pre-factoring towards the removal of the generic `gen_snapshot` artifact from the macOS host binaries (which are currently unused since we never pass a null `TargetPlatform`), which is pre-factoring towards the goal of building `gen_snapshot` binaries with an arm64 host architecture, and eliminate the need to use Rosetta during iOS and macOS Flutter builds.
Part of: https://github.com/flutter/flutter/issues/101138
Umbrella issue: https://github.com/flutter/flutter/issues/103386
Umbrella issue: https://github.com/flutter/flutter/issues/69157
No new tests since the behaviour is enforced by the compiler.
This tweaks the Flutter doctor messages for CocoaPods.
This also switches the "unknown version" error to link to the update instructions instead of the installation instructions; the user has already installed CocoaPods in this scenario.
Example error before:
```
â CocoaPods not installed.
CocoaPods is used to retrieve the iOS and macOS platform side's plugin code that responds to your plugin usage on the Dart side.
Without CocoaPods, plugins will not work on iOS or macOS.
For more info, see https://flutter.dev/platform-plugins
To install see https://guides.cocoapods.org/using/getting-started.html#installation for instructions.
```
Example error after:
```
â CocoaPods not installed.
CocoaPods is a package manager for iOS or macOS platform code.
Without CocoaPods, plugins will not work on iOS or macOS.
For more info, see https://flutter.dev/platform-plugins
For installation instructions, see https://guides.cocoapods.org/using/getting-started.html#installation
```
In a ProxiedDevicePortForwarder, there might be a race condition where the local socket has been disconnected, but the remote end was still sending new data. In this case, avoid forwarding new data to the socket.
This adds support for adding the `--wasm` flag to `flutter run` and `flutter drive`
* Emits errors if you attempt to use the skwasm renderer without the `--wasm` flag
* Emits errors if you try to use `--wasm` when not using a web device
* Uses the skwasm renderer by default if you pass `--wasm` and no `--web-renderer`
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
Also move the vm service discovery logic into platform-specific implementation of `Device`s. This is to avoid having platform-specific code in attach.dart.
Xcode 15 will be required for iOS App Store submission
> Please note that as of April 2024 all iOS and iPadOS apps submitted to the App Store must be built with a minimum of Xcode 15 and the iOS 17 SDK.
https://developer.apple.com/ios/submit/
And will also be required for Swift Package Manager support https://github.com/flutter/flutter/pull/146256.
We could swap to "required" but macOS developers don't technically need to upgrade. We can let the Store itself enforce its policies. And we can swap to Xcode 15 "required" when SPM adoption is further along.
Part of https://github.com/flutter/flutter/issues/144582
