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.
<!--
Thanks for filing a pull request!
Reviewers are typically assigned within a week of filing a request.
To learn more about code review, see our documentation on Tree Hygiene:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
-->
**Description**
While exploring some semi-related stuff, found these 2 tests using
outdated regex which does not work because AGP version in modern
templates is set in `settings.gradle.kts` and in form of
`com.android.application` instead of `com.android.tools.build:gradle`.
Apart from that, in `android_plugin_example_app_build_test.dart` deleted
all lines regarding version change (instead of comply with new way of
declaring plugin) because for a long time it's didn't work anyway:
`replaceAll` haven't find any matches and test ran on latest AGP from
template. More than that, attempt to adapt this test to modern AGP setup
failed because build is not working with AGP < 8 (I lost logs with
actual error for this case, but I believe I can reproduce if anyone
wants)
in `native_assets_agp_version_test`:
- Fixed version to comply with AGP versioning format, which is
`major.minor.patch`.
- Updated regex and version changing logic to work with
`com.android.application` format and `settings.gradle.kts` file. I
believe that version updating is desired behavior here, unlike in
`android_plugin_example_app_build_test.dart`.
- Updated `kts` syntax for declaring flavors in `build.gradle.kts` and
updated regex-based updating of this file (didn't work previously
because there wasn't actual writing to file)
didn't list any issues because there're not any regarding these tests
(or maybe I just failed to find). In any case, I think that this doesn't
require issue because fix is kinda trivial and motivation is clear.
## 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].
- [ ] 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
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>
Native asset tests use `flutter create --no-pub --template=package_ffi`.
The template used for this is checked in. It then adds extra
dependencies to checked-in packages in flutter/flutter (which have
pinned deps) in those generated templates.
It then pins all dependencies in the modified template project. This can
lead to constraint violations when flutter updates pinned dependencies,
because the template uses old constraints (which are turned from `^x` to
`=x`) and the additional dependency on flutter/flutter checked in
package brings in different pinned dependencies.
In a previous PR we already made this more robust by using flutter's
pinned versions over the the versions from the template (that are
changed from `^x` to `=x`).
Though a new upgrade of flutters pinned packages reveals that this isn't
quite sufficient: The template uses `test` at `^X`. The additional
dependency to `link_hook` doesn't depend on `test`. It therefore turns
it into `=X`. BUT `link_hooks` has a non-dev dependency on `test_core`
which is incompatible with `=X`.
=> So we relax this even more by prefering to choose (pinned) versions
of the flutter/flutter `link_hook` dependencies and (new) dev
dependencies over the template dependencies.
=> This will make use use the pinned `test` version from `link_hooks`
instead of from the template.
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>
Killing the flutter_tools parent process may leak child processes
spawned by the tools.
Also wait for the message indicating that DevTools has started before
stopping flutter_tools. If DevTools has not fully launched, then there
may be a race between DevTools startup and flutter_tools shutdown.
Fixes https://github.com/flutter/flutter/issues/159154
Speculative fix for https://github.com/flutter/flutter/issues/157640.
A few observations:
- I was a bit paranoid about indented files meaning something was parsed
incorrectly
- I removed `android.enableR8=true` (not used elsewhere)
- I removed `android.experimental.enableNewResourceShrinker=true` (not
used elsewhere)
- I matched the rest of the `jvmargs` used in the standard template file
... let's hope this does good things?
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>
Closes https://github.com/flutter/flutter/issues/158560.
I believe but am not sure as of
https://github.com/flutter/flutter/pull/159170 merging, many process
flakes that were consuming memory and in turn, making Gradle
particularly sensitive to timing out or being killing by the OS for
low-memory, have been rectified.
It is possible there are additional problems, but they aren't visible at
the moment.
I'd like to re-enable these and keep tracking their stability.
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.
Towards https://github.com/flutter/flutter/issues/51421.
```sh
flutter_tools % dart test test/integration.shard/break_on_framework_exceptions_test.dart
02:38 +29: All tests passed!
54692 ttys003 0:00.02 /opt/homebrew/bin/zsh -il
```
Requires https://github.com/flutter/flutter/pull/159115 for the process
cleanup to work properly, but this is safe to land as-is, otherwise we
still accumulate `flutter` processes over and over as each test case
runs which is not WAI.
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>
Towards https://github.com/flutter/flutter/issues/159000 as part of
debugging issues such as
https://github.com/flutter/flutter/issues/158560.
On a `bringup: true` shard, run a number of `flutter build apk` tests in
succession to try and routinely trigger timeouts and crashes, so we can
test other hypotheses on how to fix this problem (i.e. potentially
around increasing memory, changing daemon configuration, aggressively
killing processes, etc).
