The "link-dry-run" functionality was never used in flutter (even before
the recent refactoring).
I think we can remove this "link-dry-run" concept everywhere.
PR to remove this in dart-lang/native:
https://github.com/dart-lang/native/pull/1613
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Changes to original CL: The code that issues an error on unsupported
operating system in the dry-run case was missing a case for iOS and
Android
Original CL description
tl;dr Removes 50% (>1650 locs) of native asset related code in
`packages/flutter_tools`
Before this PR the invocation of dart build/link/dry-run was implemented
per OS. This lead to very large code duplication of almost identical,
but slightly different code. It also led to similarly duplicated test
code.
Almost the entire dart build/link/dry-run implementation is identical
across OSes. There's small variations:
- configuration of the build (e.g. android/macos/ios version, ios sdk,
...)
- determining target locations & copying the final shared libraries
This PR unifies the implementation by reducing the code to basically two
main functions:
* `runFlutterSpecificDartBuild` which is responsible for
- obtain flutter configuration
- perform dart build (& link)
- determine target location & install binaries
* `runFlutterSpecificDartDryRunOnPlatforms` which is responsible for a
similar (but not same):
- obtain flutter configuration
- perform dart dry run
- determine target location
these two functions will call out to helpers for the OS specific
functionality:
* `_assetTargetLocationsForOS` for determining the location of the code
assets
* `_copyNativeCodeAssetsForOS` for copying the code assets (and possibly
overriting the install name, etc)
=> Since we get rid of the code duplication across OSes and have only a
single code path for the build/link/dry-run, we can also remove the
duplicated tests that were pretty much identical across OSes.
We also harden the building code by adding asserts, e.g.
* the dry fun functionality should never be used by `flutter test`
* the `build/native_assets/<os>/native_assets.yaml` should only be used
by `flutter test` and the dry-run of `flutter run`
=> We change the tests to also comply with these invariants (so the
tests are not testing things that cannot happen in reality)
We also rename `{,Flutter}NativeAssetsBuildRunner` to disambiguate it
from the `package:native_asset_builder`'s `NativeAssetsBuildRunner`.
Reverts: flutter/flutter#155430
Initiated by: eyebrowsoffire
Reason for reverting: Postsubmit failures closing the tree. See the following examples:
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20native_assets_ios/5738/overviewhttps://ci.chromium.org/ui/p/flutter/builders/prod/Mac_arm64_mokey%20native_assets_android/583/overviewhttps://ci.chromium.org/ui/p/flutter/builders/prod/Linux_pixel_7pro%20native_assets_android/4075/overviewhttps://ci.chromium.org/u
Original PR Author: mkustermann
Reviewed By: {bkonyi, dcharkes}
This change reverts the following previous change:
tl;dr Removes 50% (>1650 locs) of native asset related code in `packages/flutter_tools`
Before this PR the invocation of dart build/link/dry-run was implemented per OS. This lead to very large code duplication of almost identical, but sligthly different code. It also led to similarly duplicated test code.
Almost the entire dart build/link/dry-run implementation is identical across OSes. There's small variations:
- configuration of the build (e.g. android/macos/ios version, ios sdk, ...)
- determining target locations & copying the final shared libraries
This PR unifies the implementation by reducing the code to basically two main functions:
* `runFlutterSpecificDartBuild` which is responsible for
- obtain flutter configuration
- perform dart build (& link)
- determine target location & install binaries
* `runFlutterSpecificDartDryRunOnPlatforms` which is responsible for a similar (but not same):
- obtain flutter configuration
- perform dart dry run
- determine target location
these two functions will call out to helpers for the OS specific functionality:
* `_assetTargetLocationsForOS` for determining the location of the code assets
* `_copyNativeCodeAssetsForOS` for copying the code assets (and possibly overriting the install name, etc)
=> Since we get rid of the code duplication across OSes and have only a single code path for the build/link/dry-run, we can also remove the duplicated tests that were pretty much identical across OSes.
We also harden the building code by adding asserts, e.g.
* the dry fun functionality should never be used by `flutter test`
* the `build/native_assets/<os>/native_assets.yaml` should only be used by `flutter test` and the dry-run of `flutter run`
=> We change the tests to also comply with these invariants (so the tests are not testing things that cannot happen in reality)
We also rename `{,Flutter}NativeAssetsBuildRunner` to disambiguate it from the `package:native_asset_builder`'s `NativeAssetsBuildRunner`.
We also reorganize the main code to make it readable from top-down and make members private where they can be.
tl;dr Removes 50% (>1650 locs) of native asset related code in
`packages/flutter_tools`
Before this PR the invocation of dart build/link/dry-run was implemented
per OS. This lead to very large code duplication of almost identical,
but slightly different code. It also led to similarly duplicated test
code.
Almost the entire dart build/link/dry-run implementation is identical
across OSes. There's small variations:
- configuration of the build (e.g. android/macos/ios version, ios sdk, ...)
- determining target locations & copying the final shared libraries
This PR unifies the implementation by reducing the code to basically two
main functions:
* `runFlutterSpecificDartBuild` which is responsible for
- obtain flutter configuration
- perform dart build (& link)
- determine target location & install binaries
* `runFlutterSpecificDartDryRunOnPlatforms` which is responsible for a
similar (but not same):
- obtain flutter configuration
- perform dart dry run
- determine target location
these two functions will call out to helpers for the OS specific
functionality:
* `_assetTargetLocationsForOS` for determining the location of the code
assets
* `_copyNativeCodeAssetsForOS` for copying the code assets (and possibly
overriting the install name, etc)
=> Since we get rid of the code duplication across OSes and have only a
single code path for the build/link/dry-run, we can also remove the
duplicated tests that were pretty much identical across OSes.
We also harden the building code by adding asserts, e.g.
* the dry fun functionality should never be used by `flutter test`
* the `build/native_assets/<os>/native_assets.yaml` should only be used
by `flutter test` and the dry-run of `flutter run`
=> We change the tests to also comply with these invariants (so the
tests are not testing things that cannot happen in reality)
We also rename `{,Flutter}NativeAssetsBuildRunner` to disambiguate it
from the `package:native_asset_builder`'s `NativeAssetsBuildRunner`.
Rolls native deps to the latest version, and cleans up deprecated field from template.
Tests:
* All the unit and integration tests for native assets. The template and dependencies are exercised in the integration test.
Since `package:native_assets_builder` already checks for having no static libraries as output, the custom check in flutter_tools is removed. The tests stubbing out the native assets builder exercising the custom check are also removed. (The integration tests now check for the error message from the native assets builder.)
Adds `-u`/`--unit-id-debug-info` arguments to `flutter symbolize` to pass paths to DWARF information for deferred loading units. The argument passed via `-u` should be of the form `N:P`, where `N` is the loading unit ID (an integer) and `P` is the path to the debug information for loading unit `N`. The DWARF information for the root loading unit can either be passed by `-d`/`--debug-info` as before or by `--unit-id-debug-info 1:<path>`.
Partial fix for https://github.com/flutter/flutter/issues/137527. Additional work is needed to adjust tools built on top of `flutter symbolize` to store and pass along this additional information appropriately when there are deferred loading units.
This change disables fuchsia in flutter_tools, most of the fuchsia logic becomes no-op, so the test cases need to be removed altogether.
This change needs to go first to avoid breaking dependencies.
Bug: b/353729557
Fixes https://github.com/flutter/flutter/issues/154903
This PR contains some refactoring. To make the actual change easier to figure out, I've tried to separate parts of the change into multiple commits for easier reviewing ð.
**I plan on cherry-picking this change to stable.**
This PR modifies the warning message regarding Java compatibility to make it consistent with the Flutter style guide.
**Current message looks like this**
```
[RECOMMENDED] If so, to keep the default AGP version 8.1.0, make
sure to download a compatible Java version
(Java 17 <= compatible Java version < Java 21).
You may configure this compatible Java version by running:
`flutter config --jdk-dir=<JDK_DIRECTORY>`
Note that this is a global configuration for Flutter.
Alternatively, to continue using your configured Java version, update the AGP
version specified in the following files to a compatible AGP
version (minimum compatible AGP version: 7.0) as necessary:
- /home/user/project/testproj/android/build.gradle
See
https://developer.android.com/build/releases/gradle-plugin for details on
compatible Java/AGP versions.
```
**After Modification**
```
To keep the default AGP version 8.1.0, download a compatible Java version
(Java 17 <= compatible Java version < Java 21). Configure this Java version
globally for Flutter by running:
flutter config --jdk-dir=<JDK_DIRECTORY>
Alternatively, to continue using your current Java version, update the AGP
version in the following file(s) to a compatible version (minimum AGP version: 7.0):
/home/user/project/testproj/android/build.gradle
For details on compatible Java and AGP versions, see
https://developer.android.com/build/releases/gradle-plugin
```
Fixes#152460
~~Fixes~~ Discovered in https://github.com/flutter/flutter/issues/153776.
To my knowledge, `Resource temporarily unavailable` when trying to run a process means that some required resource is at capacity. There may be too many processes active, not enough available ports, or some sort of blocking cache is full, etc. Feel free to independently research and see if you come to the same conclusion.
Then, it seems safe to catch and handle this within the tool's `ErrorHandlingProcessManager` abstraction, as Flutter cannot realistically do anything to prevent this issue.
Fixes https://github.com/flutter/flutter/issues/154857.
Does so by:
* adding `await chromiumLauncher.connect(chrome, false);` before the `close` call to make sure we enter[ the block ](9cd2fc90af/packages/flutter_tools/lib/src/web/chrome.dart (L521-L535))that actually tries to close chromium
* adding an `onGetTab` callback to `FakeChromeConnectionWithTab`, which the test now uses to throw a StateError upon `getTab` getting called.
## How I verified this change
1. Change `Chromium.close` from using the safer `getChromeTabGuarded` function to using the previous method of calling `ChromeConnection.getTab` directly. Do so by applying this diff:
```diff
diff --git a/packages/flutter_tools/lib/src/web/chrome.dart b/packages/flutter_tools/lib/src/web/chrome.dart
index c9a5fdab81..81bc246ff9 100644
--- a/packages/flutter_tools/lib/src/web/chrome.dart
+++ b/packages/flutter_tools/lib/src/web/chrome.dart
@@ -520,7 +520,7 @@ class Chromium {
Duration sigtermDelay = Duration.zero;
if (_hasValidChromeConnection) {
try {
- final ChromeTab? tab = await getChromeTabGuarded(chromeConnection,
+ final ChromeTab? tab = await chromeConnection.getTab(
(_) => true, retryFor: const Duration(seconds: 1));
if (tab != null) {
final WipConnection wipConnection = await tab.connect();
```
2. Then, run the test, which should correctly fail:
```
dart test test/web.shard/chrome_test.dart --name="chrome.close can recover if getTab throws a StateError"`
```
3. Revert the change from step 1 and run again. The test should now pass.
https://github.com/flutter/flutter/pull/151675 bumped module templates to AGP 8.1.
In doing so, I tried to work around a behavior change [that was new in AGP 8.0](https://developer.android.com/build/releases/past-releases/agp-8-0-0-release-notes):
> AGP 8.0 creates no SoftwareComponent by default. Instead AGP creates SoftwareComponents only for variants that are configured to be published using the publishing DSL.
by using AGP's publishing DSL to define which variants to publish in the module's ephemeral gradle files:
```
android.buildTypes.all {buildType ->
if (!android.productFlavors.isEmpty()) {
android.productFlavors.all{productFlavor ->
android.publishing.singleVariant(productFlavor.name + buildType.name.capitalize()) {
withSourcesJar()
withJavadocJar()
}
}
} else {
android.publishing.singleVariant(buildType.name) {
withSourcesJar()
withJavadocJar()
}
}
}
```
The problem is that this doesn't get applied to the plugin projects used by the module, so if a module uses any plugin it breaks. This PR fixes that by applying similar logic, but to each project (not just the module's project).
Tested manually with https://github.com/gmackall/GrayAddToApp, and also re-enabled an old test that tested this use case as a part of the PR.
Fixes: https://github.com/flutter/flutter/issues/154371
Fixes https://github.com/flutter/flutter/issues/133585.
This PR elects to add a new catch within `_handleToolError` that checks any uncaught error. This new catch will exit the tool without crashing provided the following conditions are met:
1. the error is a `ProcessException`,
2. the error message contains `git` somewhere in the message (we don't match on the entire string in case it changes or is locale-dependent), and
3. `git` does not appear to be runnable on the host system (`ProcessManager.canRun` returns `false` for git).
This is preferable to checking for runnability of `git` before we run it for 1) its simplicity and 2) lack of performance penalty for users that already have git installed (almost every single one).
This PR also does some light refactoring to runner_test.dart to make room for tests that aren't related to crash reporting.
Fixes: #154580
Previous PR: #154677
More info: https://github.com/flutter/flutter/issues/154580#issuecomment-2333799620
The errors described in the original issue [are still occurring](https://github.com/flutter/flutter/issues/154580#issuecomment-2333799620) after #154677. Before this change, the repro [broken_demo](https://github.com/rajveermalviya/broken_demo) mentioned in the original issue logs:
```shell-session
$ flutter run --release
Launching lib/main.dart on sdk gphone64 arm64 in release mode...
Running Gradle task 'assembleRelease'... 14.5s
â Built build/app/outputs/flutter-apk/app-release.apk (7.4MB)
Installing build/app/outputs/flutter-apk/app-release.apk... 739ms
Flutter run key commands.
h List all available interactive commands.
c Clear the screen
q Quit (terminate the application on the device).
W/FlutterEngineCxnRegstry(13284): Attempted to register plugin (a0.a@53b33b6) but it was already registered with this FlutterEngine (d0.c@8baa8b7).
E/flutter (13284): [ERROR:flutter/runtime/dart_vm_initializer.cc(40)] Unhandled Exception: PlatformException(channel-error, Unable to establish connection on channel., null, null)
E/flutter (13284): #0 PathProviderApi.getApplicationSupportPath (package:path_provider_android/messages.g.dart:65)
E/flutter (13284): <asynchronous suspension>
E/flutter (13284): #1 getApplicationSupportDirectory (package:path_provider/path_provider.dart:78)
E/flutter (13284): <asynchronous suspension>
E/flutter (13284): #2 _BorkenDemoHomePageState.build.<anonymous closure> (package:broken_demo/main.dart:44)
E/flutter (13284): <asynchronous suspension>
E/flutter (13284):
```
After this change:
```shell-session
$ flutter run --release
Launching lib/main.dart on sdk gphone64 arm64 in release mode...
Running Gradle task 'assembleRelease'... 15.2s
â Built build/app/outputs/flutter-apk/app-release.apk (7.4MB)
Installing build/app/outputs/flutter-apk/app-release.apk... 857ms
Flutter run key commands.
h List all available interactive commands.
c Clear the screen
q Quit (terminate the application on the device).
I/flutter (13040): path_provider: Directory: '/data/user/0/com.example.broken_demo/files'
```
This PR introduces the `dartFileName` parameter for platform plugin configurations with Dart platform implementations. This new parameter allows plugin developers to specify a custom path to the file where the `dartPluginClass` is defined.
**Implementation is opt-in**. `dartFileName` is completely optional and is taken in account only with `dartClassName`. Possibility to set `dartClassName` without `dartFileName` remains.
**Implementation is backward compatible** â existing configurations using only `dartClassName` remain fully supported. If `dartFileName` is omitted, the system falls back to the previous behavior of deriving the file name from the plugin name.
## Example
```yaml
flutter:
plugin:
platforms:
some_platform:
dartPluginClass: MyPlugin
dartFileName: 'src/my_plugin_implementation.dart'
```
fixes#152833
There are three categories of binaries produced as part of the framework artifacts:
* Those that use APIs that require entitlements and must be code-signed; e.g. gen_snapshot
* Those that do not use APIs that require entitlements and must be code-signed; e.g. Flutter.framework dylib.
* Those that do not need to be code-signed; e.g. Flutter.dSYM symbols.
We are adding the third category in https://github.com/flutter/engine/pull/54977. The Cocoon code signing aspect of this was handled in https://github.com/flutter/cocoon/pull/3890.
This ensures these files don't get copied into the build output should they appear in the artifact cache.
Issue: https://github.com/flutter/flutter/issues/154571
Fixes https://github.com/flutter/flutter/issues/154580, for the time being.
We should follow up to determine why this is necessary, but I think it is important to un-break these specific plugins for now.
`flutter downgrade` fails if you haven't used `flutter upgrade`:
```
$ flutter downgrade
There is no previously recorded version for channel "stable".
```
It's not clear what actions a user should take from this error message. Here's the new error message:
```
$ flutter downgrade
It looks like you haven't run "flutter upgrade" on channel "stable".
"flutter downgrade" undoes the last "flutter upgrade".
To switch to a specific Flutter version, see: https://flutter.dev/to/switch-flutter-version
```
Depends on https://github.com/flutter/website/pull/11098
Makes the Flutter Gradle Plugin apply the `FlutterExtension` (the class that vends `flutter.minSdkVersion`, etc) to Flutter plugins.
This allows plugin authors to use `flutter.compileSdkVersion` and the like in plugin `build.gradle` files.
Doesn't use it in templates yet - holding off till we can see how this works in the plugins repo (which will sadly have to wait till this makes the next stable ð¢ )
`DartDevelopmentServiceLauncher` was created to share the DDS launch
logic from flutter_tools with other Dart tooling.
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
Catches gradle error and throws a helpful error message that indicates
an incompatability between Java and AGP versions and how to fix the
issue.
Related issue:
[128524](https://github.com/flutter/flutter/issues/128524)
## 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.
- [ ] All existing and new tests are passing.
Native libraries that are contributed by native asset builders can depend on each other. For macOS and iOS, native libraries are repackaged into Frameworks, which renders install names that have been written into dependent libraries invalid.
With this change, a mapping between old and new install names is maintained, and install names in dependent libraries are rewritten as a final step.
Related to https://github.com/dart-lang/native/issues/190
Make sure `usesUnsupportedDependencyVersions` property exists before checking it in the Flutter Gradle plugin.
Related to: https://github.com/flutter/flutter/issues/153668 (doesn't fix, will need to cherry pick to fix).
The choice screen is irrelevant when debugging apps locally. `flutter run` creates a separate user profile for testing only. It doesn't touch users' browser settings.
Fixes https://github.com/flutter/flutter/issues/153928
Fixes https://github.com/flutter/flutter/issues/153972 (unless the cause of https://github.com/flutter/flutter/issues/153064#issuecomment-2305662791 happens to also prevent this fix from working).
In this PR, I've looked for all non-test call sites of `ChromeConnection.getTabs` and made sure are all wrapped in `try` blocks that handle `IOException` (`HttpException` is what we see in crash reporting, but I figure any `IOException` might as well be the same for all intents and purposes).
I plan on cherry-picking this the stable branch.
Currently, if creating a symlink on Windows fails due to `ERROR_ACCESS_DENIED`, you'll get an error message like:
```
Error: ERROR_ACCESS_DENIED file system exception thrown while trying to create a symlink from source to dest
```
The `source` and `dest` paths are incorrect.
This will help us debug: https://github.com/flutter/flutter/issues/153758
As of Xcode 16, App Store validation now requires that apps uploaded to the App store bundle dSYM debug information bundles for each Framework they embed.
dSYM bundles are packaged in the FlutterMacOS.xcframework shipped in the `darwin-x64-release` tools archive as of engine patches:
* https://github.com/flutter/engine/pull/54696
This copies the FlutterMacOS.framework.dSYM bundle from the tools cache to the build outputs produced by `flutter build macOS`.
Fixes: https://github.com/flutter/flutter/issues/153879
Re-lands https://github.com/flutter/flutter/pull/136880, fixes https://github.com/flutter/flutter/issues/136879.
Additions to/things that are different from the original PR:
- Adds an entry to `gradle_errors.dart` that tells people when they run into the R8 bug because of using AGP 7.3.0 (https://issuetracker.google.com/issues/242308990).
- Previous PR moved templates off of AGP 7.3.0.
- Packages repo has been moved off AGP 7.3.0 (https://github.com/flutter/packages/pull/7432).
Also, unrelatedly:
- Deletes an entry in `gradle_errors.dart` that informed people to build with `--no-shrink`. This flag [doesn't do anything](https://github.com/flutter/website/pull/11022#issuecomment-2297294421), so it can't be the solution to any error.
- Uniquely lowers the priority of the `incompatibleKotlinVersionHandler`. This is necessary because the ordering of the errors doesn't fully determine the priority of which handler we decide to use, but also the order of the log lines. The kotlin error lines often print before the other error lines, so putting it last in the list of handlers isn't sufficient to lower it to be the lowest priority handler.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
I am making an assumption `OutputMode.none` should _really_ mean
`OutputMode.failuresOnly`, that is, if we ever get a non-zero exit code,
we still want to know why. If I've somehow misunderstood that, LMK and
I'm happy to revert this PR or make adjustments.
This fixes the bug where if you were to do:
```sh
git clone https://github.com/myuser/fork-of-flutter
cd fork-of-flutter
./bin/flutter update-packages
```
You now get:
1. An actual error message, versus no output at all.
2. A warning that a common reason is not tracking a remote, with
instructions to fix it.
Closes https://github.com/flutter/flutter/issues/148569.
Not so long ago I remember a very informal conversation that went something like this:
> @matanlurey: I wish I could pass `--dev` or something to `flutter` to run from source.
>
> @christopherfujino: I get what you want, but I don't want to overload the tool with more dev-only things. I would consider a script like `flutter-dev` that does that thing, though.
>
> @matanlurey: Cool, I might send a PR!
So uh, here it is 6-9 months later. Suggestions welcome.
Reverts: flutter/flutter#152487
Initiated by: gmackall
Reason for reverting: I forgot that I need to override the compileSdkVersion in the AGP 8.0 [instance of this test](ef9cd32f5a/dev/devicelab/bin/tasks/android_java17_dependency_smoke_tests.dart (L19))
Original PR Author: gmackall
Reviewed By: {reidbaker}
This change reverts the following previous change:
Updates `compileSdk`, `targetSdk`, and `ndk` versions (former 2 to latest, latter to the version of the ndk we are hosting on CIPD).
Summary of changes:
- Updates mentioned template values
- `compileSdk` 35 requires AGP 8.0+, so updated to 8.1 in many places.
- This also necessitated Gradle upgrades in most places
- This also necessitated moving the `package` xml attribute to the AGP `namespace` field in a couple places (test + template).
- Some tests use the output of `flutter create` but then use intentionally lower AGP versions. [I downgraded the `compileSdk` in these tests.](fee34fd61a)
- [Stopped lockfile generation](82324a2570) script from hitting the `hello_world` example because it uses `.kts` gradle files.
- One test needed [some Gradle options we had already added to templates](6aa187b4b6).
Updates `compileSdk`, `targetSdk`, and `ndk` versions (former 2 to latest, latter to the version of the ndk we are hosting on CIPD).
Summary of changes:
- Updates mentioned template values
- `compileSdk` 35 requires AGP 8.0+, so updated to 8.1 in many places.
- This also necessitated Gradle upgrades in most places
- This also necessitated moving the `package` xml attribute to the AGP `namespace` field in a couple places (test + template).
- Some tests use the output of `flutter create` but then use intentionally lower AGP versions. [I downgraded the `compileSdk` in these tests.](fee34fd61a)
- [Stopped lockfile generation](82324a2570) script from hitting the `hello_world` example because it uses `.kts` gradle files.
- One test needed [some Gradle options we had already added to templates](6aa187b4b6).
The stream subscriptions in the device's VmService are used by other parts of FlutterVmService and other components throughout flutter_tools. Components that listen to streams should not call VmService.streamCancel because that will interfere with other users who still want the events.
See https://github.com/flutter/flutter/issues/153049
See https://github.com/flutter/flutter/issues/153563
The Flutter tool has a bug where removing the last Flutter plugin does not correctly update the CocoaPods integration.
This adds a test to ensure that the generated Swift package is properly updated when the last Flutter plugin is removed.
See: https://github.com/flutter/flutter/issues/11819#issuecomment-2289782626
When DevTools is active HotRunner.attach makes a deferred RPC to a DevTools service. That RPC appears to cause issues if it executes at the wrong time during the hot restart.
Passing the --no-devtools flag works around this by disabling the RPC.
See https://github.com/flutter/flutter/issues/153049
The test should not assume that a stream of bytes delivers them in a
certain chunked order (e.g. all bytes of a line are delivered in one
chunk and the newline comes in another chunk).
Instead it should use a line splitter to obtain individual lines and can
match those against expectations.
This fragile test is broken after [0] which combines writing a string
together with the newline instead of seperately.
[0] https://dart-review.googlesource.com/c/sdk/+/378024
Hide the `--web-renderer` option in the Flutter Tool. The defaults already cover all fully supported modes:
- `flutter build web` provides canvaskit + dart2js
- `flutter build web --wasm` provides skwasm + dart2wasm
We do not want to encourage production usage of any other permutations (e.g. `auto` or `html`), in particular those that simply do not work (e.g. `skwasm` + dart2js).
Fixes https://github.com/flutter/flutter/issues/140096
Fixes https://github.com/flutter/flutter/issues/151786
Reverts: flutter/flutter#152358
Initiated by: zanderso
Reason for reverting: Speculative revert to determine whether this PR is related to https://github.com/flutter/flutter/issues/153026
Original PR Author: andrewkolos
Reviewed By: {christopherfujino}
This change reverts the following previous change:
Contributes to fixing https://github.com/flutter/flutter/issues/137184.
Cleaned up version of earlier PR, https://github.com/flutter/flutter/pull/152187.
This PR guards all the writes to `Process::stdin` by wrapping them with `ProcessUtils.writelnToStdinUnsafe`. This way, if any writes fail, we should at least get a stacktrace in our crash reporting.
Opening a Swift package in Xcode generates `.build` and `.swiftpm` directories. These should be ignored as they contain intermediary build artifacts that aren't meant to be checked-in.
Part of https://github.com/flutter/flutter/issues/148018
Nullable types for values in map patterns require the key to be present.
Since the 'uri' key is not always present in DDS exception responses,
this was causing us to fall back to throwing a StateError.
Fixes https://github.com/flutter/flutter/issues/152684
Sets up tests that verify we can build a fresh counter app across our Gradle/AGP/Kotlin support range.
Post submit only, because the suite takes ~30 minutes to run, and I expect it to be _somewhat_ rare that we break only one of these versions (and therefore it doesn't get caught by existing presubmits).
On Xcode 16 beta 3 stderr is:
```
** BUILD FAILED **
```
stdout is:
```
Writing result bundle at path:
/var/folders/fm/wjzsj_z95ydgn4khxqgbtqx000mfq2/T/flutter_tools.PeJZlH/flutter_ios_build_temp_dirqmiKld/temporary_xcresult_bundle
error: lib/main.dart:13:11: Error: A value of type 'String' can't be assigned to a variable of type 'int'.
int x = 'String';
^
Target kernel_snapshot_program failed: Exception
Failed to package /Users/m/Projects/test_create.
note: Disabling previews because SWIFT_VERSION is set and SWIFT_OPTIMIZATION_LEVEL=-O, expected -Onone (in target 'Runner' from project 'Runner')
note: Run script build phase 'Thin Binary' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'Runner' from project 'Runner')
note: Run script build phase 'Run Script' will be run during every build because the option to run the script phase "Based on dependency analysis" is unchecked. (in target 'Runner' from project 'Runner')
```
The tool output of `flutter build ios` shows both:
```
Building com.example.testCreate for device (ios-release)...
Automatically signing iOS for device deployment using specified development team
in Xcode project: S8QB4VV633
Running Xcode build...
Xcode build done. 10.1s
Failed to build iOS app
Error output from Xcode build:
â³
** BUILD FAILED **
Xcode's output:
â³
Writing result bundle at path:
/var/folders/fm/wjzsj_z95ydgn4khxqgbtqx000mfq2/T/flutter_tools.Dgnlxc/flutt
er_ios_build_temp_dirpKTDdk/temporary_xcresult_bundle
error: lib/main.dart:13:11: Error: A value of type 'String' can't be
assigned to a variable of type 'int'.
int x = 'String';
^
Target kernel_snapshot_program failed: Exception
Failed to package /Users/magder/Projects/test_create.
note: Disabling previews because SWIFT_VERSION is set and
SWIFT_OPTIMIZATION_LEVEL=-O, expected -Onone (in target 'Runner' from
project 'Runner')
note: Run script build phase 'Run Script' will be run during every build
because the option to run the script phase "Based on dependency analysis" is
unchecked. (in target 'Runner' from project 'Runner')
note: Run script build phase 'Thin Binary' will be run during every build
because the option to run the script phase "Based on dependency analysis" is
unchecked. (in target 'Runner' from project 'Runner')
Encountered error while building for device.
```
The point of this test is that you can see the error `int x = 'String';` error in the tool output. https://github.com/flutter/flutter/issues/72608#issuecomment-797473109
I think just updating the test to check stderr or stdout is sufficient without touching the tool behavior.
Fixes https://github.com/flutter/flutter/issues/151553
If Swift Package Manager is enabled, the tool generates a Swift package at `<ios/macos>/Flutter/ephemeral/Packages/FlutterGeneratedPluginSwiftPackage/`. This Swift package is how the tool adds plugins to the Flutter project.
SwiftPM is strictly enforces platform versions: you cannot depend on a Swift package if its supported version is higher than your own.
On iOS, we use the project's minimum deployment version for the generated Swift package. If a plugin has a higher requirement, you'll need to update your project's minimum deployment version. The generated Swift package is automatically updated the next time you run the tool.
This updates macOS to do the same thing.
Fixes https://github.com/flutter/flutter/issues/146204
This reverts commit 7cdc23b3e1.
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`.
Turns out just supporting the right value for `kDebugMode` was a lot simpler than I thought. Debug builds used to never go through the build system code path when using `flutter run`, but now that we have wasm this can occur with the run command.
This should address https://github.com/flutter/flutter/issues/148850
Updates the expected steps in the async function defined within `stepping_project.dart`.
The Dart web team is updating the async semantics of DDC to bring them in line with the other backends. Currently, the DDC async semantics don't adhere to the Dart spec and this can lead to inconsistent and surprising results.
However, the step-over operation doesn't work well yet with the new DDC async semantics. In the long run we intend to improve this but until then the debug stepper will have sporadic results that we can't model well with this test. When we are able to fix the stepper functionality, we will return this test to cover more of the async function being stepped over.
Reverts: flutter/flutter#152049
Initiated by: cbracken
Reason for reverting: iOS builds failing in post-submit
Original PR Author: loic-sharma
Reviewed By: {jmagman}
This change reverts the following previous change:
Changes:
1. Enables Swift Package Manager by default on the main/master channel
2. Fixes tests that fail if Swift Package Manager is enabled
Corresponding docs change: https://github.com/flutter/website/pull/10938
Addresses https://github.com/flutter/flutter/issues/151567
When the `"${native_assets_path}"*.framework` glob doesn't resolve anything, the bash will run the loop once with the original unglobbed value: `/path/to/native/assets/*.framework`. Skip this case to prevent the build from failing when there are no frameworks to sign.
To reproduce this build failure:
1. Enable native assets in the Flutter tool: `flutter config --enable-native-assets`
2. Create a Flutter project with the default template: `flutter create test_native_assets`
3. Add a build hook that does nothing (`hook/build.dart`).
4. Try to build/run the app: `flutter run --debug -d macos`
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
For the necessary background knowledge, see the flutter.dev content on [Resolution-aware image assets](https://docs.flutter.dev/ui/assets/assets-and-images#resolution-aware) and [Conditional bundling of assets based on app flavor](https://docs.flutter.dev/ui/assets/assets-and-images#conditional-bundling-of-assets-based-on-app-flavor) if you don't have a basic understanding of these features.
Fixes https://github.com/flutter/flutter/issues/151813 by using unique temporary directories, per asset file, for transformations. Currently, only a single directory is used and the name of the temporary files was based only on the basename of files. This means that `assets/image.png` and `assets/2x/image.png` would share an output path (`<temp dir path>/image.png`), causing a race. If this quick and rough explanation is a bit confusing, the original issueâ#151813âprovides a full repro and correct identification of the exact cause of the failure that can occur in the asset transformation process.
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 will make
* `flutter run` have source maps enabled by default
* `flutter build` have source maps disabled by default
which mirrors what happens already today with the js compilers.
For local development this works quite well - even better than with
dart2js (see dart2js issues in [0]).
We do have some follow-up items for source maps in dart2wasm compiler,
see [1]
[0]
[flutter/flutter/issues/151641](https://github.com/flutter/flutter/issues/151641)
[1]
[dart-lang/sdk/issues/56232](https://github.com/dart-lang/sdk/issues/56232)
Stop trying to roll the dependencies for native assets automatically.
They are under active development (pre 1.0.0), and have frequent breaking changes. I'll be rolling these manually.
(We have the same setup in the Dart SDK, not auto-rolling dart-lang/native via DEPS.)
Related comment:
* https://github.com/flutter/flutter/pull/151539#issuecomment-2221134824
Stop running link hooks in debug mode.
Rationale: link hooks only get access to tree-shaking info in release builds, so they can't do anything meaningful in debug builds. Debug builds should be fast as development cycle, so running less is better.
More details:
* https://github.com/dart-lang/native/issues/1252
Also: rolls packages to latest versions.
## Implementation details
The decision whether linking is enabled is made as follows:
* For normal builds `build_info.dart::BuildMode` is used to determine whether Dart is compiled in JIT or AOT mode.
* Testers always run in JIT, so no linking.
* Native asset dry runs only run for JIT builds (e.g only when hot reload and hot restart are enabled).
## Testing
The integration test is updated to output an asset for linking if `BuildConfig.linkingEnabled` is true, and to output an asset for bundling directly if linking is not enabled.
These changes allow to override existing native endorsed (federated & inline) plugins with e.g. non-endorsed plugin implementations via direct dependencies as described in the section *Platform implementation selection* in the [design doc](https://docs.google.com/document/d/1LD7QjmzJZLCopUrFAAE98wOUQpjmguyGTN2wd_89Srs).
```yaml
# pubspec.yaml
name: example
dependencies:
my_plugin: ^0.0.1
my_plugin_android_alternative: ^0.0.1
```
Closes#80374, closes#59657
Related: Override Dart plugins (#87991, #79669)
