Now that we're in a monorepo, it makes sense to use the in-tree engine
by default when using `--local-engine` or `--local-web-sdk` rather than
looking for a sibling directory like we used to.
This PR rolls in a number of breaking changes from dart-lang/native:
* `BuildMode` is no longer part of the protocol, so Flutter no longer
passes it in.
* This means all code dealing with the name conflict between
`native_assets_cli.BuildMode` and `flutter_tools.BuildMode` has been
cleaned up.
* Also, the logs no longer mention the build mode.
* The tests still exercise both modes, because linking only happens in
release mode.
* `OS` is no longer part of the main protocol, but of the "code"
"protocol extension".
* The code now aligns more with `OS?` being nullable in a bunch of
places, since it is nullable if there's no code assets.
* The OS-specific config is nested in an object per OS.
* `CCompilerConfig`s fields are non-nullable now.
* So instead of passing an object with nullable fields around, a null
instead of the object is returned in various places.
* `FileSystem` is now passed in to the native assets builder.
This PR contains no feature changes.
This PR will need to be followed up by restricting what environment
variables are passed in (similar to
https://github.com/dart-lang/native/pull/1764), I will do this in a
follow up PR.
Tests:
* All existing features should be covered by existing tests.
Work towards https://github.com/flutter/flutter/issues/143299.
Work towards https://github.com/flutter/flutter/issues/160043.
---
This PR implements, end-to-end, support for `matchesGoldenFile` when (a)
running with `package:integration_test` (b) on a device, such as an
Android emulator, Android device, iOS simulator, or iOS device, where
the _runner_ of a test file does not have process and local-file system
access.
There are multiple parts to this PR; I could make it smaller than 1K
lines, but the bulk of that is tests, and it would mean landing PRs that
are incomplete and unused, which does not seem useful - so instead here
is a quick overview of the PR's contents - questions/feedback welcome,
and I am willing to break code out or land incremental refactors if
requested.
1. Augmented `flutter_platform.dart` (used for iOS and Android), similar
to
[`flutter_web_platform.dart`](1398dc7eec/packages/flutter_tools/lib/src/test/flutter_web_platform.dart (L117-L128)),
now creates and uses
[`test_golden_comparator.dart`](https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/test/test_golden_comparator.dart)
to proxy calls (coming from the VM service protocol) for golden-file
updates and comparisons to a `flutter_tester` process. A full
explanation of how (or why) it works this way is too hard to include
here, but see https://github.com/flutter/flutter/pull/160215 for more
details.
1. Added `VmServiceProxyGoldenFileComparator`, which is a currently
unused (outside of a single e2e test) comparator that forwards calls to
`compare` and `update` to the VM service protocol (of which, the other
side of this is implemented above, in `flutter_platform.dart`. The idea
is that this comparator would be used automatically when running in an
integration test on a device that requires it (similar to how web works
today), but that is **not** wired up yet and requires additional work in
`flutter_tools`.
1. Added two unit tests (of both the client and server), and a full
e2e-test using it to run `matchesGoldenFile`.
Towards https://github.com/flutter/flutter/issues/160692.
Prior to `flutter_template_images: 4.3.0`, the `app_shared` directory
was required.
In 4.3.0 it was forked back out to `app`
(https://pub.dev/packages/flutter_template_images/changelog), as the
`skeleton` template has been removed, and the `skeleton` template was
the (only) reason for `app_shared` (to share code between `app` and
`skeleton`).
This is a NOP change tested by existing tests.
Now that "auto" is not supported anymore, it makes more sense to make
this dart define false by default. And there's no need to pass
`FLUTTER_WEB_AUTO_DETECT=false` anymore.
dart_style 3.0.1 comes with some minor style fixes:
https://github.com/dart-lang/dart_style/blob/main/CHANGELOG.md#301
This PR applies this fixes in bulk across the repository. (Otherwise,
the next person touching these files would have been the one updating
them to the new format by running the formatter).
This auto-formats all *.dart files in the repository outside of the
`engine` subdirectory and enforces that these files stay formatted with
a presubmit check.
**Reviewers:** Please carefully review all the commits except for the
one titled "formatted". The "formatted" commit was auto-generated by
running `dev/tools/format.sh -a -f`. The other commits were hand-crafted
to prepare the repo for the formatting change. I recommend reviewing the
commits one-by-one via the "Commits" tab and avoiding Github's "Files
changed" tab as it will likely slow down your browser because of the
size of this PR.
---------
Co-authored-by: Kate Lovett <katelovett@google.com>
Co-authored-by: LongCatIsLooong <31859944+LongCatIsLooong@users.noreply.github.com>
Part of https://github.com/flutter/flutter/issues/102983.
`<FlutterManifest>.generateSyntheticPackage` _never_ meant generate a
synthetic package 😒, it only meant "we _might_ need to generate a
synthetic package because localizations are being generated and the
default, unless otherwise specified, is to generate a synthetic
package".
Renamed as `generateLocalizations` and added some strategic TODOs in
places where removing the `package:flutter_gen` feature
(https://github.com/flutter/flutter/issues/102983) will allow us to
cleanup this erroneous code and technical debt.
Simplified a bit code (just a refactor) in the process, and fixes a bug
that `flutter packages get` would generate internationalization files
even if `flutter: generate: true` was not present in `pubspec.yaml` that
was revealed as part of fixing this up.
/cc @sigurdm.
These tests depend on line numbers that `dart format` is changing.
Pre-format the files in question and adjust the tests so they continue
to pass when the entire repo is formatted.
Part of https://github.com/flutter/flutter/issues/160043, makes it
easier to add https://github.com/flutter/flutter/pull/160131.
This PR has no functional changes to any of the code, but does refactor
both the code and tests:
- Makes a number of always non-null but not migrated to non-null
properties, well, not-null
- Creates two concrete methods (`update` and `compare` versus a
positional nullable boolean)
- Uses type signatures instead of `String?` to explain the possible
results of the methods
- Renames the mysterious `shellPath` variable to `flutterTesterBinPath`
- Expands and rewrites internally-facing doc comments
- Moves `WebRenderer` environment variable setting to
`flutter_web_platform.dart`
- Makes the tests have less duplication, and check for update/compare
cases
After this PR, I can use it in the non-web branch of the Flutter tool
without any hacks or TODOS :)
/cc @eyebrowsoffire (trivial web refactoring), @camsim99 (changes being
made to tool).
When running `dart format` over these lines the `// ignore` ended up on
a line where it wasn't properly ignoring the lint. This adjusts the
placement of `// ignore`s so they will continue to ignore the right
thing even after the code is auto formatted.
I am hoping that if we do this now the large PR that formats the entire
repo will go in smoother without manual intervention.
The previous attempt at this fix was assuming that the tool's file
system was a `LocalFileSystem`, but in reality it's a `LocalFileSystem`
wrapped in an `ErrorHandlingFileSystem`. This change takes this into
account.
Fixes https://github.com/flutter/flutter/issues/160082
Fixes https://github.com/flutter/flutter/issues/156962
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
The generated widget_preview_scaffold project needs to explicitly
reference the assets from the parent project's pubspec.yaml. This change
updates flutter widget-preview start to read the parent project's
pubspec.yaml and add references to the assets listed to the
widget_preview_scaffold's pubspec.yaml. If generate: true is set in the
parent project, a reference to the autogenerated flutter_gen package is
manually added to the widget_preview_scaffold's package_config.json.
This is the initial tooling work for Flutter Widget Previews, adding two
commands: `flutter widget-preview start` and `flutter widget-preview
clean`.
The `start` command currently only checks to see if
`.dart_tool/widget_preview_scaffold/` exists and creates a new Flutter
project using the widget_preview_scaffold template if one isn't found.
The widget_preview_scaffold template currently only contains some
placeholder files and will be updated to include additional code
required by the scaffold.
The `clean` command simply deletes `.dart_tool/widget_preview_scaffold/`
if it's found.
This change also includes some refactoring of the `create` command in
order to share some project creation logic without requiring `flutter
widget-preview start` to spawn a new process simply to run `flutter
create -t widget_preview .dart_tool/widget_preview_scaffold`.
Related issue: https://github.com/flutter/flutter/issues/115704
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
This PR introduces a `NativeAssetsManifest.json` next to the
`AssetManifest.bin` and `FontManifest.json`. This removes the need for
embedding the native assets mapping inside the kernel file and enables
decoupling native assets building and bundling from the kernel
compilation in flutter tools. This means `flutter run` no longer does a
dry run of `hook/build.dart` hooks.
(It also means all isolate groups will have the same native assets.
However, since Flutter does not support `Isolate.spawnUri` from kernel
files, this is not a regression.)
Implementation details:
* g3 is still using kernel embedding.
https://github.com/flutter/flutter/pull/142016 introduced an argument to
embed a `native_assets.yaml` inside `flutter attach` and `flutter run`
(the outer flutter process), but it is not used in `flutter assemble`
(the inner process when doing `flutter run`). So, those arguments need
to still be respected. However, all other logic related to embedding a
yaml encoding in the kernel file has been removed.
* All dry-run logic has been removed. 🎉
* The `KernelSnapshot` target no longer depends on the
`InstallCodeAssets` target. Instead, the various OS-specific
"BundleAsset" targets now depend on the `InstallCodeAssets` target. The
`InstallCodeAssets` invokes the build hooks and produces the
`NativeAssetsManifest.json`. The various "BundleAsset" commands
synchronize the `NativeAssetsManifest.json` to the app bundle.
* `InstallCodeAssets` produces a `native_assets.json`, which is renamed
to `NativeAssetsManifest.json` in the various "Bundle" targets. This
means that all unit tests of the "Bundle" targets now need to create
this file. (Similar to how `app.dill` is expected to exist because
`KernelSnapshot` is a dependency of the "Bundle" targets.)
* Because dynamic libraries need to be code signed (at least on iOS and
MacOS), the bundling of the dylibs is _not_ migrated to reuse
`_updateDevFS` (which is used for ordinary assets). Only the 2nd and 3rd
invocation of `flutter assemble` from `xcodebuild` has access to the
code signing identity.
Relevant tests:
* test/integration.shard/isolated/native_assets_test.dart - runs
`flutter run` with native assets including hot restart and hot reload.
TODO:
* Undo engine-roll in this PR after engine has rolled in.
Issue:
* https://github.com/flutter/flutter/issues/154425
Related PRs:
* https://dart-review.googlesource.com/c/sdk/+/388161
* https://github.com/flutter/engine/pull/56727
## 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.
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
This PR attempts to improve clarity of androids section of `flutter
doctor -v` output by providing explicit information about which JDK is
being used and how to configure a different one if needed.
### Before
```console
• Java binary at: /Users/user/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents/jbr/Contents/Home/bin/java
```
### After
1. When JDK is from Android Studio:
```console
• Java binary at: /Users/users/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents/jbr/Contents/Home/bin/java
This is the JDK bundled with latest Android Studio installation
To manually set a custom JDK path, use: `flutter config --jdk-dir="path/to/jdk"`
```
2. When JDK is from JAVA_HOME env variable:
```console
• Java binary at: /Users/user/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents/jbr/Contents/Home/bin/java
This JDK is specified by JAVA_HOME environment variable
To manually set a custom JDK path, use: `flutter config --jdk-dir="path/to/jdk"`
```
3. When path to JDK is set in flutter config:
```console
• Java binary at: /Users/user/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents/jbr/Contents/Home/bin/java
This JDK was found in system PATH
To change current JDK, run: `flutter config --jdk-dir="path/to/jdk"`
```
4. When java binary is found in PATH (as fallback)
```console
• Java binary at: /Users/user/Applications/Android Studio Ladybug Feature Drop 2024.2.2 Canary 2.app/Contents/jbr/Contents/Home/bin/java
This JDK is specified in Flutter configuration
To manually set a custom JDK path, use: `flutter config --jdk-dir="path/to/jdk"`
```
### Motivation
I think it's described in
https://github.com/flutter/flutter/issues/153156#issuecomment-2336814991.
TLDR; many developers struggle with Java-related issues and more verbose
doctor's output will (presumably) improve DX in that part.
fixes#153156
## 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.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
See https://github.com/flutter/flutter/issues/159154.
See https://github.com/flutter/flutter/pull/159169.
Before this PR, it appeared we were accidentally leaking (keeping
active) `flutter_tester` instances (or any test device) after `flutter
run` completion, even if the runner was not explicitly detached. I
_think_ this is a bug, but I'll check with the tools team and possibly
@jonahwilliams before finalizing this.
/cc @jason-simmons
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
The dart-lang/native repository contains a `Target` class that is almost
not needed anymore. The remaining uses are mainly due to kernel asset
mapping (which we may be able to remove in the future).
This PR removes usages of that `Target` (in favor of `Architecture`)
class in most places in flutter tools.
This makes the code also cleaner because we no longer have an implicit
assumption that
a `List<Target>` all belong to the same operating system.
Closes https://github.com/flutter/flutter/issues/20949.
Signals (such as SIGTERM or SIGKILL) end up flowing through
`exitWithHooks`, which in turn, after running hooks, call `exit().` That
means, as a result, any `try { } finally { }` guarded execution may
_not_ run, which happens to also be how `flutter_tester` instances are
cleaned up if they have not terminated.
This PR adds in-progress `flutter_tester` runs (or any platform
`flutter_platform` supports) to the shutdown hooks, guaranteeing that
the finalizers (which in turn, kill the process) are _always_ executed
as long as either the test completes, _or_ `exitWithHooks` is called.
The existing integration tests (`integration.shard/test_test.dart`)
still pass as well.
It's possible that the tool can be in the process of shutting down,
which could result in the temp directory being deleted after the
shutdown hooks run before we check if `output` exists. If this happens,
we shouldn't crash but just carry on as if no devices were found as the
tool will exit on its own.
Fixes https://github.com/flutter/flutter/issues/141892
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
Currently the `NativeAsset` target in flutter tools is responsible for
two things:
* performing the dart build (in the app as well as all transitive pub
dependencies)
* taking output (shared libraries) from this build and copying them
around
This intermingling of responsibilities leads to more complex code and
potentially unnecessary work: If the source code changed (e.g. `.c`
files change) we have to run the dart build again. But doing so may
result in the same shared libraries (e.g. adding comments to the `.c`
code). Currently we're going to copy the shared libraries despite them
having not changed, which then may cause upstream things to be dirtied
(if it's based on timestamp of files) and re-built.
Instead this PR splits this `NativeAsset` into the two orthogonal pieces
* `DartBuild` target that is responsible for the dart build
* `InstallCodeAssets` that is responsible for copying shared libraries
to the right place and producing a `native_assets.yaml`.
This decoupling is also preparation for a future where a dart build can
produce other kinds of assets (e.g. data assets) and is used in the web
build as well. (The web build would use `DartBuild` but not
`InstalCodeAssets`).
After the dart build is done, the flutter tool has to bundle the
produced shared libraries, which it does that by copying them around.
Though the code assumed that all code assets are shared libraries to be
bundled, whereas in fact one can have code assets without any actual
code (ones that are installed on the target system already or artificial
code assets whose symbols get resolved from executable / process).
=> Using non-bundled code assets currently results in null pointer
exceptions and/or cast errors.
=> We update the copy code to only operate on code assets that have a
shared library to bundle.
We also update the copy routines by removing copy&past'ed - but slightly
different - printing code into the shared caller function.
In release builds linking of native assets is enabled. The build step is
only a temprary step, it's output is given to the link step which then
returns all final assets (effectively a map-reduce system). Assets that
aren't sent to a specific linker could be conceptually viewed as sent to
a linker that will emit it's input as-is.
=> The code currently took output of build & link step and therefore
accumulated assets that aren't explicitly sent to a linker twice.
=> This led to performing work twice for those (e.g. copying them twice)
This PR changes this such that if linking mode is enabled, we only rely
on the output of the link phase.
That in return means many tests that mock the native asset builds need
to be updated to mock the output of the link phase.
This started happening after moving DDS to launch from `dart
development-service` rather than `DartDevelopmentService` (see
33b402d24c) . This state error was
originally meant to be thrown when some string parsing failed, but is
currently wrapping the `DartDevelopmentServiceException`.
Fixes https://github.com/flutter/flutter/issues/158537
I was poking around in logger.dart when I noticed a few classes have unnecessary exposed member variables. This PR reduces visibility of these in the pursuit of making these classes slightly easier to grok.
<details>
<summary> Pre-launch checklist </summary>
</details>
Cleans up https://github.com/flutter/flutter/pull/155800. In summary, `ResidentRunner`/`FlutterDevice` have branching behavior around logging that depends on the type of `DeviceLogReader` on the `FlutterDevice` instance. Let's instead move this behavior to the `DeviceLogReader` implementations.
My apologies for the large diff. Much of this is a refactor that was a bit too difficult to separate into its own commits.
Here are the main two changes
* Replaces the mutable `connectedVmService` field on the `DeviceLogReader` class with a new method `provideVmService`. This serves largely the same purpose as the mutable field, but it allows for asynchronous code. This is where we put the logic that used to exist in `FlutterDevice.tryInitLogReader`.
* Removes the `tryInitLogReader` method from `FlutterDevice`. This method served to set the `appPid` field on the `FlutterDevice`'s `DeviceLogReader` instance. This was only used in the case of Android to filter out logs unrelated to the flutter app coming from the device, so we can move this logic to `AdbLogReader`'s implementation of `provideVmService`.
Closes https://github.com/flutter/flutter/issues/158012.
This is (effectively) a user-facing NOP, which is exchanging an
on-by-default command-line argument (`--implicit-pubspec-resolution`)
for an off-by-default global feature flag
(`explicit-package-dependencies`). It matches the mental model better,
is less painstaking to maintain and feed throughout, and will be easier
to globally flip on/off in a future PR.
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
In the future, it will be possible for Swift Package Manager to be enabled on one but not all platforms (see https://github.com/flutter/flutter/issues/151567#issuecomment-2455941279).
This moves the `usesSwiftPackageManager` property from the platform-agnostic `Project` to the platform-specific `IosProject` and `MacOSProject`.
This will allow the `IosProject` and `MacOSProject` to return different values for `usesSwiftPackageManager` in the future. For now, both of these projects will always return the same value.
Part of https://github.com/flutter/flutter/issues/151567
In the future, it will be possible for Swift Package Manager to be enabled on one but not all platforms (see https://github.com/flutter/flutter/issues/151567#issuecomment-2455941279).
This updates the `.flutter-plugin-dependencies` file format to separate iOS's and macOS's SwiftPM enablement. For now, these platforms will always have the same value.
This `.flutter-plugin-dependencies` file is read by our CocoaPods scripts to determine whether we should use CocoaPods or not to inject plugins.
Part of https://github.com/flutter/flutter/issues/151567
Fixes https://github.com/flutter/flutter/issues/153777.
To summarize that issue, `ErrorHandlingFileSystem.systemTempDirectory` calls [`LocalFileSystem.systemTempDirectory`](45c8881eb2/packages/flutter_tools/lib/src/base/file_system.dart (L229)), which makes a `Directory.createSync` call, which can throw exceptions that _should_ be handled and result in a graceful tool exit (e.g. insufficient storage). However, we aren't catching those, hence this issue.
All we need to do is wrap that call with the `FileSystemException`-handling logic we already have in the tool. See the diff.
I don't think I'll be cherry-picking this since 1) it's not an extremely common crash and 2) users can probably pick apart the crash message and figure out that they need to clear some storage space to proceed.
<details>
<summary> Pre-launch checklist </summary>
</details>
Removes duplicated constants and ensures consistency by using package:vm_service as a source of truth for RPC error codes for requests made with package:vm_service.
Work towards https://github.com/flutter/flutter/issues/56591.
I explicitly want an LGTM from @andrewkolos @jmagman @jonahwilliams before merging.
---
After this PR, `<Plugin>.isDevDependency` is resolved based on the following logic, IFF:
- The plugin comes from a package _A_ listed in the app's package's `dev_dependencies: ...`
- The package _A_ is not a normal dependency of any transitive non-dev dependency of the app
See [`compute_dev_dependencies_test.dart`](51676093a3/packages/flutter_tools/test/general.shard/compute_dev_dependencies_test.dart) for probably the best specification of this behavior.
We (still) do not write the property to disk (i.e. it never makes it to `.flutter-plugins-dependencies`), so there is no impact to build artifacts at this time; that would come in a follow-up PR (and then follow-up follow-up PRs for the various build systems in both Gradle and Xcode to actually use that value to omit dependencies).
Some tests had to be updated; for the most part it was updating the default `ProcessManager` because a call to `dart pub deps --json` is now made in code that computes what plugins are available, but there should be no change in behavior.
_/cc @jonasfj @sigurdm for FYI only (we talked on an internal thread about this; see https://github.com/dart-lang/sdk/issues/56968)._
_/cc @camsim99 @cbracken @johnmccutchan for visibility on the change._
Almost all of the code is just adopting to changes to the APIs of
`package:native_assets_builder`, `package:native_assets_cli` and
`package:native_toolchain_c`
There's only two semantic changes
* Removes a test that checks for a verification error if a build hook
produces a static library if the preferred linking mode is dynamic:
=> The test is written in a very hacky way. By monkey patching the build
config.json that flutter build actually made. This monkey patching
relies on package:cli_config which is now no longer used.
=> The actual code that checks for this mismatch lives in
dart-lang/native repository and is tested there. So there's really no
need to duplicate that.
* The `package:native_assets_builder` no longer knows about code assets.
This is something a user of that package (e.g. flutter tools) adds. Now
the dry-run functionality will invoke build hooks who produce code
assets without an architecture.
=> The `package:native_assets_builder` used to expand such a code asset
to N different code assets (one for each supported architecture)
=> This logic was now moved to flutter tools. => In the near future
we're going to this dry-run complexity, which will then also get rid of
this uglyness (of expanding to all archs of an OS).
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
