While doing some hacking on `Cache` in https://github.com/flutter/flutter/pull/158081, I noticed that [`Cache.test`](de93182753/packages/flutter_tools/lib/src/cache.dart (L139)) allows the caller to tell Cache to use some given directory as the flutter root (instead of depending on the static global [`Cache.flutterRoot`](4f3976a4f2/packages/flutter_tools/lib/src/cache.dart (L206))). This has a default value, `/cache`. However, `/cache` is an unintuitive name for the root directory of a Flutter installation.
This led to confusion when updating some tests. I wanted to create `/bin/cache/engine-dart-sdk.stamp` for tests, but in reality I needed to create `/cache/bin/cache/engine-dart-sdk.stamp`.
This PR changes this default to the current directory of the file system (which I'm guessing is `/` for all intents and purposes).
<details>
<summary> Pre-launch checklist </summary>
</details>
This is to handle Google testing failures for https://github.com/flutter/flutter/pull/158126.
We want to update G3 to provide this parameter before merging the full change.
Testing is not needed because the change is no-op.
Work towards https://github.com/flutter/flutter/issues/157819. **No behavior changes as a result of this PR**.
Based on a proof of concept by @jonahwilliams (https://github.com/flutter/flutter/pull/157818).
The existence of this flag (which for the time being, defaults to `true`) implies the following:
1. The (legacy, deprecated) `.flutter-plugins` file is not generated:
https://docs.flutter.dev/release/breaking-changes/flutter-plugins-configuration
2. The (legacy, deprecated) `package:flutter_gen` is not synthetically generated:
https://github.com/flutter/website/pull/11343
(awaiting website approvers, but owners approve this change)
This change creates `useImplicitPubspecResolution` and plumbs it through as a required variable, parsing it from a `FlutterCommand.globalResults` where able. In tests, I've defaulted the value to `true` 100% of the time - except for places where the value itself is acted on directly, in which case there are true and false test-cases (e.g. localization and i10n based classes and functions).
I'm not extremely happy this needed to change 50+ files, but is sort of a result of how inter-connected many of the elements of the tools are. I believe keeping this as an explicit (flagged) argument will be our best way to ensure the default behavior changes consistently and that tests are running as expected.
These are the versions we use in test, as of https://github.com/flutter/flutter/pull/157617.
Motivated by noticing a warning with the old template version:
```
This Android Gradle plugin (8.1.0) was tested up to compileSdk = 33 (and compileSdkPreview = "UpsideDownCakePrivacySandbox").
You are strongly encouraged to update your project to use a newer
Android Gradle plugin that has been tested with compileSdk = 35.
```
Documents when to use `throwToolExit` and how to use it.
Replaces every invocation of `throw ToolExit` with `throwToolExit` and makes the former impossible; this is so that every user will at least (hypothetically) have the chance to read the documentation attached to `throwToolExit` (and if we change parameters in the future they will all flow through one place).
Reverts: flutter/flutter#157032
Initiated by: gmackall
Reason for reverting: https://github.com/flutter/flutter/pull/157032#issuecomment-2436336078
Original PR Author: gmackall
Reviewed By: {reidbaker, bartekpacia}
This change reverts the following previous change:
I recently noticed the following log when building an app in verbose mode:
```
This Android Gradle plugin (8.1.0) was tested up to compileSdk = 33 (and compileSdkPreview = "UpsideDownCakePrivacySandbox").
You are strongly encouraged to update your project to use a newer
Android Gradle plugin that has been tested with compileSdk = 35.
```
It looks like AGP would like us to use a newer AGP version if we want to use compileSdk 35 (which we do). This pr upgrades the tests, in advance of updating the templates.
I recently noticed the following log when building an app in verbose mode:
```
This Android Gradle plugin (8.1.0) was tested up to compileSdk = 33 (and compileSdkPreview = "UpsideDownCakePrivacySandbox").
You are strongly encouraged to update your project to use a newer
Android Gradle plugin that has been tested with compileSdk = 35.
```
It looks like AGP would like us to use a newer AGP version if we want to use compileSdk 35 (which we do). This pr upgrades the tests, in advance of updating the templates.
Fixes https://github.com/flutter/flutter/issues/157359
Prevents Flutter.xcframework.dSYM from being copied into the App.framework folder. I am not 100% positive if there are cases where it's valid to have multiple dSYMs in that folder, so I'm just string matching and filtering out `Flutter.xcframework.dSYM`
The SourceVisitor uses the engineVersion parameter to determine whether it needs to check for changes to artifacts or if it can assume that artifacts are unmodified from a versioned build of the engine. engineVersion is set based on whether the Artifacts instance sets the isLocalEngine property.
CachedLocalWebSdkArtifacts (instantiated when the --local-web-sdk flag is used) was only setting isLocalEngine if --local-engine was also used. This caused the build system to ignore changes to the files in the locally built flutter_web_sdk when using --local-web-sdk alone.
This PR renames Artifacts.isLocalEngine to usesLocalArtifacts in order to clarify what it means. It also changes CachedLocalWebSdkArtifacts to always enable usesLocalArtifacts.
There have been various requests for this for a while. See https://github.com/flutter/flutter/issues/96283 for an example. This has become more important with dart2wasm builds in the mix, as the profiling versions of the dart2wasm builds are a lot less debuggable than the debug versions. Most of this is already wired up so it just requires taking out a few explicit checks for it and making sure that we compile with the right optimization levels when compiling debug.
Reverts: flutter/flutter#154061
Initiated by: QuncCccccc
Reason for reverting: might be the reason that cause Framework tree to red
Original PR Author: bartekpacia
Reviewed By: {gmackall, reidbaker}
This change reverts the following previous change:
This PR resolves#151166
Fixes https://github.com/flutter/flutter/issues/156304.
Also fixes https://github.com/flutter/flutter/issues/155449.
Unfortunately, because the error handler only sees one line at a time, it is hard to make this handling any more specific than this. If we run in to another jlink related error (unlikely) between now and when we phase out support for AGP 8.2.0 and below, we might have trouble differentiating them. We should delete the error handler when we phase out support for those versions.
Example of handled error output:
```
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':shared_preferences_android:compileReleaseJavaWithJavac'.
> Could not resolve all files for configuration ':shared_preferences_android:androidJdkImage'.
> Failed to transform core-for-system-modules.jar to match attributes {artifactType=_internal_android_jdk_image, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}.
> Execution failed for JdkImageTransform: /Users/mackall/Library/Android/sdk/platforms/android-34/core-for-system-modules.jar.
> Error while executing process /Users/mackall/Desktop/JDKs/21/jdk-21.0.2.jdk/Contents/Home/bin/jlink with arguments {--module-path /Users/mackall/.gradle/caches/8.9/transforms/2890fec03da42154757073d3208548e5-79660961-f91d-4df2-90bc-b9a3f2a270bd/transformed/output/temp/jmod --add-modules java.base --output /Users/mackall/.gradle/caches/8.9/transforms/2890fec03da42154757073d3208548e5-79660961-f91d-4df2-90bc-b9a3f2a270bd/transformed/output/jdkImage --disable-plugin system-modules}
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
BUILD FAILED in 1s
Running Gradle task 'assembleRelease'... 2,100ms
ââ Flutter Fix ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
â [!] This is likely due to a known bug in Android Gradle Plugin (AGP) versions less than 8.2.1, when â
â 1. setting a value for SourceCompatibility and â
â 2. using Java 21 or above. â
â To fix this error, please upgrade your AGP version to at least 8.2.1. The version of AGP that your project uses is likely defined in: â
â /Users/mackall/development/BugTesting/fifth/android/settings.gradle, â
â in the 'plugins' closure (by the number following "com.android.application"). â
â Alternatively, if your project was created with an older version of the templates, it is likely â
â in the buildscript.dependencies closure of the top-level build.gradle: â
â /Users/mackall/development/BugTesting/fifth/android/build.gradle, â
â by the number following "com.android.tools.build:gradle:". â
â â
â For more information, see: â
â https://b.corp.google.com/issues/294137077 â
â https://github.com/flutter/flutter/issues/156304 â
âââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
Gradle task assembleRelease failed with exit code 1
```
This is simply removing unnecessary parenthesis from various places. This change is because of a change to the unnecessary_parentesis lint that will trigger there. Here is the CL https://dart-review.googlesource.com/c/sdk/+/390161.
- https://github.com/dart-lang/linter/issues/4996
If anything else is needed please let me know.
I'd like to ask for this PR to wait a bit until the bots are run again on that CL so that I can be sure nothing else will trigger, I will come back here and update this whenever everything is complete. Thanks!
This PR willing to fix issue when `flutter doctor` validator can't determine version of Android Studio EAP.
These are before/after outputs of `flutter doctor -v` showcasing change in behaviour of validator. Each output has 3 `Android Studio` sections, 1 for stable and 2 for different EAP versions.
<details>
<summary>before, (stable, 3.24.3), 2 issues related to versions of Android Studio</summary>
```console
[â] Flutter (Channel stable, 3.24.3, on macOS 14.7 23H124 darwin-arm64, locale en-RU)
⢠Flutter version 3.24.3 on channel stable at /Users/samer/fvm/versions/stable
⢠Upstream repository https://github.com/flutter/flutter.git
⢠Framework revision 2663184aa7 (4 weeks ago), 2024-09-11 16:27:48 -0500
⢠Engine revision 36335019a8
⢠Dart version 3.5.3
⢠DevTools version 2.37.3
[â] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
⢠Android SDK at /Users/samer/Library/Android/sdk
⢠Platform android-35, build-tools 34.0.0
⢠Java binary at: /Users/samer/Library/Java/JavaVirtualMachines/jbr-17.0.7/Contents/Home/bin/java
⢠Java version OpenJDK Runtime Environment JBR-17.0.7+7-964.1-nomod (build 17.0.7+7-b964.1)
⢠All Android licenses accepted.
[â] Xcode - develop for iOS and macOS (Xcode 16.0)
⢠Xcode at /Applications/Xcode-16.0.app/Contents/Developer
⢠Build 16A242d
⢠CocoaPods version 1.15.2
[â] Chrome - develop for the web
⢠Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[â] Android Studio (version 2024.1)
⢠Android Studio at /Users/samer/Applications/Android Studio Koala Feature Drop 2024.1.2.app/Contents
⢠Flutter plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/9212-flutter
⢠Dart plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/6351-dart
⢠Java version OpenJDK Runtime Environment (build 17.0.11+0-17.0.11b1207.24-11852314)
[!] Android Studio (version unknown)
⢠Android Studio at /Users/samer/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents
⢠Flutter plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/9212-flutter
⢠Dart plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/6351-dart
â Unable to determine Android Studio version.
⢠Java version OpenJDK Runtime Environment (build 21.0.3+-79915917-b509.11)
[!] Android Studio (version unknown)
⢠Android Studio at /Users/samer/Applications/Android Studio.app/Contents
⢠Flutter plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/9212-flutter
⢠Dart plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/6351-dart
â Unable to determine Android Studio version.
⢠Java version OpenJDK Runtime Environment (build 21.0.3+-79915917-b509.11)
[â] IntelliJ IDEA Ultimate Edition (version EAP IU-243.12818.47)
⢠IntelliJ at /Users/samer/Applications/IntelliJ IDEA Ultimate.app
⢠Flutter plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/9212-flutter
⢠Dart plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/6351-dart
[â] VS Code (version 1.94.0)
⢠VS Code at /Applications/Visual Studio Code.app/Contents
⢠Flutter extension version 3.98.0
[â] Connected device (5 available)
⢠sdk gphone64 arm64 (mobile) ⢠emulator-5554 ⢠android-arm64 ⢠Android 15 (API 35) (emulator)
⢠iPhone (ÐÐ¸Ñ Ð°Ð¸Ð») (mobile) ⢠00008020-001254DA1E39002E ⢠ios ⢠iOS 17.6.1 21G93
⢠macOS (desktop) ⢠macos ⢠darwin-arm64 ⢠macOS 14.7 23H124 darwin-arm64
⢠Mac Designed for iPad (desktop) ⢠mac-designed-for-ipad ⢠darwin ⢠macOS 14.7 23H124 darwin-arm64
⢠Chrome (web) ⢠chrome ⢠web-javascript ⢠Google Chrome 129.0.6668.90
! Error: Browsing on the local area network for ÐÐ¸Ñ Ð°Ð¸Ð» ÐовоÑелÑÑевâs iPad. Ensure the device is unlocked and attached with a cable or associated with the same local area network as this Mac.
The device must be opted into Developer Mode to connect wirelessly. (code -27)
[â] Network resources
⢠All expected network resources are available.
! Doctor found issues in 2 categories.
```
</details>
<details>
<summary>after, no issues regarding Android Studio</summary>
```console
[!] Flutter (Channel [user-branch], 3.26.0-1.0.pre.383, on macOS 14.7 23H124 darwin-arm64, locale en-RU)
! Flutter version 3.26.0-1.0.pre.383 on channel [user-branch] at /Users/samer/projects/flutter
Currently on an unknown channel. Run `flutter channel` to switch to an official channel.
If that doesn't fix the issue, reinstall Flutter by following instructions at https://flutter.dev/setup.
⢠Upstream repository git@github.com:Sameri11/flutter.git
⢠FLUTTER_GIT_URL = git@github.com:Sameri11/flutter.git
⢠Framework revision 852508425d (20 minutes ago), 2024-10-07 21:22:45 +0500
⢠Engine revision 683a14c1f1
⢠Dart version 3.6.0 (build 3.6.0-326.0.dev)
⢠DevTools version 2.40.0
⢠If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update
checks and upgrades.
[â] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
⢠Android SDK at /Users/samer/Library/Android/sdk
⢠Platform android-35, build-tools 34.0.0
⢠Java binary at: /Users/samer/Library/Java/JavaVirtualMachines/jbr-17.0.7/Contents/Home/bin/java
⢠Java version OpenJDK Runtime Environment JBR-17.0.7+7-964.1-nomod (build 17.0.7+7-b964.1)
⢠All Android licenses accepted.
[â] Xcode - develop for iOS and macOS (Xcode 16.0)
⢠Xcode at /Applications/Xcode-16.0.app/Contents/Developer
⢠Build 16A242d
⢠CocoaPods version 1.15.2
[â] Chrome - develop for the web
⢠Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[â] Android Studio (version 2024.1)
⢠Android Studio at /Users/samer/Applications/Android Studio Koala Feature Drop 2024.1.2.app/Contents
⢠Flutter plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/9212-flutter
⢠Dart plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/6351-dart
⢠Java version OpenJDK Runtime Environment (build 17.0.11+0-17.0.11b1207.24-11852314)
[â] Android Studio (version 2024.2.2)
⢠Android Studio at /Users/samer/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents
⢠Flutter plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/9212-flutter
⢠Dart plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/6351-dart
⢠Java version OpenJDK Runtime Environment (build 21.0.3+-79915917-b509.11)
[â] Android Studio (version 2024.2.1)
⢠Android Studio at /Users/samer/Applications/Android Studio.app/Contents
⢠Flutter plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/9212-flutter
⢠Dart plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/6351-dart
⢠Java version OpenJDK Runtime Environment (build 21.0.3+-79915917-b509.11)
[â] IntelliJ IDEA Ultimate Edition (version EAP IU-243.12818.47)
⢠IntelliJ at /Users/samer/Applications/IntelliJ IDEA Ultimate.app
⢠Flutter plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/9212-flutter
⢠Dart plugin can be installed from:
ð¨ https://plugins.jetbrains.com/plugin/6351-dart
[â] VS Code (version 1.94.0)
⢠VS Code at /Applications/Visual Studio Code.app/Contents
⢠Flutter extension version 3.98.0
[â] Connected device (5 available)
⢠sdk gphone64 arm64 (mobile) ⢠emulator-5554 ⢠android-arm64 ⢠Android 15 (API 35) (emulator)
⢠iPhone (ÐÐ¸Ñ Ð°Ð¸Ð») (mobile) ⢠00008020-001254DA1E39002E ⢠ios ⢠iOS 17.6.1 21G93
⢠macOS (desktop) ⢠macos ⢠darwin-arm64 ⢠macOS 14.7 23H124 darwin-arm64
⢠Mac Designed for iPad (desktop) ⢠mac-designed-for-ipad ⢠darwin ⢠macOS 14.7 23H124 darwin-arm64
⢠Chrome (web) ⢠chrome ⢠web-javascript ⢠Google Chrome 129.0.6668.90
! Error: Browsing on the local area network for ÐÐ¸Ñ Ð°Ð¸Ð» ÐовоÑелÑÑевâs iPad. Ensure the device is unlocked and attached with a cable or
associated with the same local area network as this Mac.
The device must be opted into Developer Mode to connect wirelessly. (code -27)
[â] Network resources
⢠All expected network resources are available.
! Doctor found issues in 1 category.
```
</details>
Logic behind these changes explained in https://github.com/flutter/flutter/issues/121925#issuecomment-2352826925fixes#121925
**Tests**: updated existing tests by adding version checking, but I don't mind writing new ones if necessary â please tell me if so.
Fix JS compilation to use the command 'compile js' instead of using
snapshot names to invoke dart2js
The Dart SDK is switching all tools to use AOT snapshots instead of JIT
snapshots and using snapshot names directly causes things to break.
Fixes https://github.com/flutter/flutter/issues/155755
When building the asset bundle during, the `--flavor` option isn't considered when searching for assets from dependencies. This PR fixes that.
It's possible that when initially implementing this feature, I thought that flavor-conditional assets didn't make sense for packages. While I still think that way regarding pub packages, using this feature makes a lot more sense for monorepo projects.
<details>
<summary> Pre-launch checklist </summary>
</details>
Powershell v6+ use the executable name `pwsh.exe` instead of
`powershell.exe`. This change adds support for determining the Windows
version on systems that solely use `pwsh.exe` and don't have
`powershell.exe` on the `PATH`.
Fixes#156189.
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
Migrates existing instantions of `--template plugin_ffi` to deal with Android 15 16kb memory pages.
Issue:
* https://github.com/flutter/flutter/issues/155933
@reidbaker I could only find migrations that run from the root application. However the file needing to be migrated is a plugin. The plugin is being referenced from the example in the example dir and that's where the migrator is run, so I wrote the code so that it walks up to find the plugin. Do you know of a way to run migrators to non-root projects? (Can we even safely do so, e.g. the non-root could be in the pub cache, could be a different project on the users' system etc. So maybe checking if we are in the examples dir is the only sane thing to do?)
Tests:
* Added unit tests in `test/general.shard/android/migrations/cmake_android_16k_pages_migration_test.dart`
Dart2js updated its CLI to support generating a 'dump-info' json file by passing a "--stage" option. The "dump-info-all" stage performs a full compilation (from the provided dill) and then also generates the dump info file.
Tested via the `flutter-dev` CLI locally. This results in the same output but with the addition of an extra `main.dart.js.info.json` file.
This pull request aims to improve code readability, based on feedback gathered in a recent design doc.
<br>
There are two factors that hugely impact how easy it is to understand a piece of code: **verbosity** and **complexity**.
Reducing **verbosity** is important, because boilerplate makes a project more difficult to navigate. It also has a tendency to make one's eyes gloss over, and subtle typos/bugs become more likely to slip through.
Reducing **complexity** makes the code more accessible to more people. This is especially important for open-source projects like Flutter, where the code is read by those who make contributions, as well as others who read through source code as they debug their own projects.
<hr>
<br>
The following examples show how pattern-matching might affect these two factors:
<details> <summary><h3>Example 1 (GOOD)</h3> [click to expand]</summary>
```dart
if (ancestor case InheritedElement(:final InheritedTheme widget)) {
themes.add(widget);
}
```
Without using patterns, this might expand to
```dart
if (ancestor is InheritedElement) {
final InheritedWidget widget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(widget);
}
}
```
Had `ancestor` been a non-local variable, it would need to be "converted" as well:
```dart
final Element ancestor = this.ancestor;
if (ancestor is InheritedElement) {
final InheritedWidget inheritedWidget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(theme);
}
}
```
</details>
<details> <summary><h3>Example 2 (BAD) </h3> [click to expand]</summary>
```dart
if (widget case PreferredSizeWidget(preferredSize: Size(:final double height))) {
return height;
}
```
Assuming `widget` is a non-local variable, this would expand to:
```dart
final Widget widget = this.widget;
if (widget is PreferredSizeWidget) {
return widget.preferredSize.height;
}
```
<br>
</details>
In both of the examples above, an `if-case` statement simultaneously verifies that an object meets the specified criteria and performs a variable assignment accordingly.
But there are some differences: Example 2 uses a more deeply-nested pattern than Example 1 but makes fewer useful checks.
**Example 1:**
- checks that `ancestor` is an `InheritedElement`
- checks that the inherited element's `widget` is an `InheritedTheme`
**Example 2:**
- checks that `widget` is a `PreferredSizeWidget`
(every `PreferredSizeWidget` has a `size` field, and every `Size` has a `height` field)
<br>
<hr>
I feel hesitant to try presenting a set of cut-and-dry rules as to which scenarios should/shouldn't use pattern-matching, since there are an abundance of different types of patterns, and an abundance of different places where they might be used.
But hopefully the conversations we've had recently will help us converge toward a common intuition of how pattern-matching can best be utilized for improved readability.
<br><br>
- resolves https://github.com/flutter/flutter/issues/152313
- Design Doc: [flutter.dev/go/dart-patterns](https://flutter.dev/go/dart-patterns)
This PR addresses an issue where the `--target-platform` flag was not being respected when building APKs in debug mode. Previously, debug builds would always include `x86` and `x64` architectures, regardless of the specified target platform. This change ensures that the `--target-platform` flag is honored across all build modes, including debug.
To achieve this, `BuildApkCommand` has been slightly changed to become responsible for list of archs that should be built in the current run,rather than just parsing arguments. Previously, this responsibility was distributed to gradle, which could be frustrating (in my opinion)
Fixes#153359
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/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.
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
`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
`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
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.
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.