Provisioning updates and device registration were disabled when
development team was specified in the xcode project. This lead to build
error when provisioning profile was not present. Now provisioning
updates and device registration are enabled when tool builds codesigned
archive. This will allow to build the iOS version of app without
launching xcode in order to enforce provisioning profile updates.
Issues fixed by this PR.
* https://github.com/flutter/flutter/issues/139212
* https://github.com/flutter/flutter/issues/113977
* https://github.com/flutter/flutter/issues/121702 (partly because
author asks for possibility of passing xcode flags like
allowProvisioningUpdates)
## 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] All existing and new tests are passing.
This test was merging two ZeroExecutionTimeValidationResults into a new
ValidationResult with an actual execution duration set rather than
Duration.zero.
Fixes https://github.com/flutter/flutter/issues/161918
The bootstrapping for the DDC module format and library bundle module
format contained a preamble to dynamically set the meta tag to ensure
the document is parsed as utf-8. This doesn't work as the page has
already been parsed at that point. Instead, it should go in the html
directly.
The meta tag should not affect the AMD module format, as require.js
already ensures any loaded scripts are parsed as utf-8.
This tag in general is needed to parse this string correctly:
https://github.com/dart-lang/sdk/blob/main/sdk/lib/core/uri.dart#L4100
This is a follow-up to PR
https://github.com/flutter/flutter/pull/161276.
## 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 `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [ ] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [ ] All existing and new tests are passing.
_Run integration tests for the project_ is not an accurate statement, as
there is nothing inherently about `flutter_driver` that is for
integration tests (for example, it could be just plain automation,
benchmarking, etc).
In addition, clarifies what the most common two arguments might be and
their defaults.
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
Closes https://github.com/flutter/flutter/issues/161449.
~3 LOC, with 203 lines of tests (including an e2e integration test that
it actually works).
Feedback welcome!
(The reason I'm working on this is the ability to pass environment
variables makes it much easier and less hacky to make
`android_engine_test` configurable, i.e. have different expected outputs
for OpenGLES/Vulkan, compare screenshots locally for deflaking, etc).
This gets us closer to enabling [hot
reload](https://github.com/dart-lang/sdk/issues/54934) on the web as
this format is a prerequisite. Historically, we added support for the
DDC module format only to enable hot reload, but that format is not
feasible for the goal, so we added the DDC library bundle format. The
DDC library bundle format is currently represented as the combination of
the `ddc` module format and `canary`. We no longer need to support the
old DDC module format.
- Adds build artifacts to build the SDKs for this format (but only in
sound mode as unsound is unsupported), and removes said artifacts for
the DDC module format.
- Update artifact maps and constants to add the new format and remove
the old format.
- Adds handling of the `canaryFeatures` flag.
- Update dwds to 24.3.0 and use the new
`FrontendServerDdcLibraryBundleStrategyProvider`.
- Add bootstrap code for the new format. Kept DDC module format
bootstrap code as it's used internally.
- Updates tests.
I ran `spinning_square` with the new module format to verify that it can
run.
## 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].
- [ ] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [X] All existing and new tests are passing.
Closes https://github.com/flutter/flutter/issues/160218.
Basically, replaces `String?` with `sealed class TestCompilerResult {}`,
and ensures `errorMessage` is propogated.
We'll be using this path now for _all_ integration tests (not just for
web-specific things), so I'd like to get error messages.
Closes https://github.com/flutter/flutter/issues/160219.
This hard-coded package configuration is no longer strictly correct
as-of Dart 3.6.0; a pub _workspace_
(https://dart.dev/tools/pub/workspaces) can appear at a higher-level
than a package, and if the package is part of the workspace, tooling is
expected to (automatically) find `.dart_tool/package_config.json` at a
higher-level.
For example, the _engine_ sub-repo uses a
[workspace](9fd5bddc65/engine/src/flutter/pubspec.yaml (L82)),
which means that, for example,
`%ENGINE%/tools/engine_tool/.dart_tool/package_config.json` will _never_
exist (it will be at `%ENGINE%/.dart_tools/package_config.json`.
As currently defined, the test-golden comparator interface will fail
with a package that uses workspaces. By removing the flag (and letting
automatic `--packages` resolution occur), I _believe_ the problem is
automatically resolved (but I'll let CI prove that for us).
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
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.
Reverts: flutter/flutter#152487
Initiated by: gmackall
Reason for reverting: I forgot that I need to override the compileSdkVersion in the AGP 8.0 [instance of this test](ef9cd32f5a/dev/devicelab/bin/tasks/android_java17_dependency_smoke_tests.dart (L19))
Original PR Author: gmackall
Reviewed By: {reidbaker}
This change reverts the following previous change:
Updates `compileSdk`, `targetSdk`, and `ndk` versions (former 2 to latest, latter to the version of the ndk we are hosting on CIPD).
Summary of changes:
- Updates mentioned template values
- `compileSdk` 35 requires AGP 8.0+, so updated to 8.1 in many places.
- This also necessitated Gradle upgrades in most places
- This also necessitated moving the `package` xml attribute to the AGP `namespace` field in a couple places (test + template).
- Some tests use the output of `flutter create` but then use intentionally lower AGP versions. [I downgraded the `compileSdk` in these tests.](fee34fd61a)
- [Stopped lockfile generation](82324a2570) script from hitting the `hello_world` example because it uses `.kts` gradle files.
- One test needed [some Gradle options we had already added to templates](6aa187b4b6).
Updates `compileSdk`, `targetSdk`, and `ndk` versions (former 2 to latest, latter to the version of the ndk we are hosting on CIPD).
Summary of changes:
- Updates mentioned template values
- `compileSdk` 35 requires AGP 8.0+, so updated to 8.1 in many places.
- This also necessitated Gradle upgrades in most places
- This also necessitated moving the `package` xml attribute to the AGP `namespace` field in a couple places (test + template).
- Some tests use the output of `flutter create` but then use intentionally lower AGP versions. [I downgraded the `compileSdk` in these tests.](fee34fd61a)
- [Stopped lockfile generation](82324a2570) script from hitting the `hello_world` example because it uses `.kts` gradle files.
- One test needed [some Gradle options we had already added to templates](6aa187b4b6).
The stream subscriptions in the device's VmService are used by other parts of FlutterVmService and other components throughout flutter_tools. Components that listen to streams should not call VmService.streamCancel because that will interfere with other users who still want the events.
See https://github.com/flutter/flutter/issues/153049
See https://github.com/flutter/flutter/issues/153563
Hide the `--web-renderer` option in the Flutter Tool. The defaults already cover all fully supported modes:
- `flutter build web` provides canvaskit + dart2js
- `flutter build web --wasm` provides skwasm + dart2wasm
We do not want to encourage production usage of any other permutations (e.g. `auto` or `html`), in particular those that simply do not work (e.g. `skwasm` + dart2js).
Fixes https://github.com/flutter/flutter/issues/140096
Fixes https://github.com/flutter/flutter/issues/151786
Reverts: flutter/flutter#152358
Initiated by: zanderso
Reason for reverting: Speculative revert to determine whether this PR is related to https://github.com/flutter/flutter/issues/153026
Original PR Author: andrewkolos
Reviewed By: {christopherfujino}
This change reverts the following previous change:
Contributes to fixing https://github.com/flutter/flutter/issues/137184.
Cleaned up version of earlier PR, https://github.com/flutter/flutter/pull/152187.
This PR guards all the writes to `Process::stdin` by wrapping them with `ProcessUtils.writelnToStdinUnsafe`. This way, if any writes fail, we should at least get a stacktrace in our crash reporting.
Opening a Swift package in Xcode generates `.build` and `.swiftpm` directories. These should be ignored as they contain intermediary build artifacts that aren't meant to be checked-in.
Part of https://github.com/flutter/flutter/issues/148018
Nullable types for values in map patterns require the key to be present.
Since the 'uri' key is not always present in DDS exception responses,
this was causing us to fall back to throwing a StateError.
Fixes https://github.com/flutter/flutter/issues/152684
If Swift Package Manager is enabled, the tool generates a Swift package at `<ios/macos>/Flutter/ephemeral/Packages/FlutterGeneratedPluginSwiftPackage/`. This Swift package is how the tool adds plugins to the Flutter project.
SwiftPM is strictly enforces platform versions: you cannot depend on a Swift package if its supported version is higher than your own.
On iOS, we use the project's minimum deployment version for the generated Swift package. If a plugin has a higher requirement, you'll need to update your project's minimum deployment version. The generated Swift package is automatically updated the next time you run the tool.
This updates macOS to do the same thing.
Fixes https://github.com/flutter/flutter/issues/146204
This reverts commit 7cdc23b3e1.
The failure in the `native_assets_test` integration test on Windows was caused by the DevTools process not being shutdown by the `ColdRunner` when running the profile mode portion of the test. This resulted in the test being unable to clean up the project created by the test as DevTools was still holding onto a handle within the directory. This PR adds back the mistakenly removed DevTools shutdown logic in the `ColdRunner`.
Turns out just supporting the right value for `kDebugMode` was a lot simpler than I thought. Debug builds used to never go through the build system code path when using `flutter run`, but now that we have wasm this can occur with the run command.
This should address https://github.com/flutter/flutter/issues/148850
Reverts: flutter/flutter#152049
Initiated by: cbracken
Reason for reverting: iOS builds failing in post-submit
Original PR Author: loic-sharma
Reviewed By: {jmagman}
This change reverts the following previous change:
Changes:
1. Enables Swift Package Manager by default on the main/master channel
2. Fixes tests that fail if Swift Package Manager is enabled
Corresponding docs change: https://github.com/flutter/website/pull/10938
Addresses https://github.com/flutter/flutter/issues/151567
1. Instead of getting the `FULL_PRODUCT_NAME` Xcode build setting (`Runner.app`) instead use `PRODUCT_NAME` since most places really want the product name, and the extension stripping wasn't correct when the name contained periods.
2. Don't instruct the user to open the `xcarchive` in Xcode if it doesn't exist.
Fixes https://github.com/flutter/flutter/issues/140212
For the necessary background knowledge, see the flutter.dev content on [Resolution-aware image assets](https://docs.flutter.dev/ui/assets/assets-and-images#resolution-aware) and [Conditional bundling of assets based on app flavor](https://docs.flutter.dev/ui/assets/assets-and-images#conditional-bundling-of-assets-based-on-app-flavor) if you don't have a basic understanding of these features.
Fixes https://github.com/flutter/flutter/issues/151813 by using unique temporary directories, per asset file, for transformations. Currently, only a single directory is used and the name of the temporary files was based only on the basename of files. This means that `assets/image.png` and `assets/2x/image.png` would share an output path (`<temp dir path>/image.png`), causing a race. If this quick and rough explanation is a bit confusing, the original issueâ#151813âprovides a full repro and correct identification of the exact cause of the failure that can occur in the asset transformation process.
Reverts: flutter/flutter#146593
Initiated by: zanderso
Reason for reverting: Consistently failing `Windows_android native_assets_android` as in https://ci.chromium.org/ui/p/flutter/builders/prod/Windows_android%20native_assets_android/2533/overview
Original PR Author: bkonyi
Reviewed By: {christopherfujino, kenzieschmoll}
This change reverts the following previous change:
This change is a major step towards moving away from shipping DDS via Pub.
The first component of this PR is the move away from importing package:dds to launch DDS. Instead, DDS is launched out of process using the `dart development-service` command shipped with the Dart SDK. This makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the removal of instances of DevTools being served manually by the flutter_tool, instead relying on DDS to serve DevTools. This will be consistent with how the standalone Dart VM serves DevTools, tying the DevTools lifecycle to a live DDS instance. This will allow for the removal of much of the logic needed to properly manage the lifecycle of the DevTools server in a future PR. Also, by serving DevTools from DDS, users will no longer need to forward a secondary port in remote workflows as DevTools will be available on the DDS port.
There's two remaining circumstances that will prevent us from removing DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory profiles
This PR also includes some refactoring around `DebuggingOptions` to reduce the number of debugging related arguments being passed as parameters adjacent to a `DebuggingOptions` instance.
This change is a major step towards moving away from shipping DDS via
Pub.
The first component of this PR is the move away from importing
package:dds to launch DDS. Instead, DDS is launched out of process using
the `dart development-service` command shipped with the Dart SDK. This
makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the
removal of instances of DevTools being served manually by the
flutter_tool, instead relying on DDS to serve DevTools. This will be
consistent with how the standalone Dart VM serves DevTools, tying the
DevTools lifecycle to a live DDS instance. This will allow for the
removal of much of the logic needed to properly manage the lifecycle of
the DevTools server in a future PR. Also, by serving DevTools from DDS,
users will no longer need to forward a secondary port in remote
workflows as DevTools will be available on the DDS port. This code is currently
commented out and will be enabled in a future PR.
There's two remaining circumstances that will prevent us from removing
DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory
profiles
This PR also includes some refactoring around `DebuggingOptions` to
reduce the number of debugging related arguments being passed as
parameters adjacent to a `DebuggingOptions` instance.
