<!--
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.
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?
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.
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.
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).
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
**PR Title:**
Remove block and line comments when detecting `'.flutter-plugins'` in `settings.gradle`
---
**Description:**
This PR modifies the `configureLegacyPluginEachProjects` function to remove block (`/* ... */`) and line (`// ...`) comments from the `settings.gradle` or `settings.gradle.kts` file content before checking for the presence of the `'.flutter-plugins'` string. This ensures that only uncommented, meaningful code is considered during the detection, preventing false positives when the string appears within comments.
**Why is this change necessary?**
In some cases, the `'.flutter-plugins'` string may be present inside comments in the `settings.gradle` file. The existing implementation does not account for this and may incorrectly detect the string even when it's commented out. This can lead to unintended behavior, such as configuring plugin projects when it is not necessary.
By removing comments before performing the check, we prevent false positives and ensure that the detection logic is accurate, only acting when the `'.flutter-plugins'` string is present in active code.
**Changes Made:**
- **Added comment removal logic:**
- Removed block comments (`/* ... */`) using the regular expression `/(?s)\/\*.*?\*\//`.
- The `(?s)` flag enables dot-all mode, allowing `.` to match newline characters.
- Removed line comments (`// ...`) using the regular expression `/(?m)\/\/.*$`.
- The `(?m)` flag enables multi-line mode, so `^` and `$` match the start and end of each line.
- Combined both comment removal steps into a single chain for efficiency.
- **Updated the string detection:**
- The check for `'.flutter-plugins'` is now performed on the uncommented content of the `settings.gradle` file.
- This ensures that only meaningful, uncommented code is considered during detection.
**Issue Fixed:**
- Fixes [#155484](https://github.com/flutter/flutter/issues/155484)
---
---
If you need any further assistance or have questions, feel free to reach out!
---
**Links:**
- [Contributor Guide]
- [Tree Hygiene]
- [Flutter Style Guide]
- [Features we expect every widget to implement]
- [CLA]
- [flutter/tests]
- [breaking change policy]
- [Discord]
- [Data Driven Fixes]
The test was immediately checking the contents of stdout after the daemon indicated that the hot reload had completed. This could cause a race since the reloaded code may not have had time to execute.
Fixes https://github.com/flutter/flutter/issues/158245
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).
Currently the bot that runs `flutter update-packages` makes PRs that
fail due to native asset integration tests failing.
The root cause is due to incompatible versions on `package:logging`. The
bot tries to upgrade `package:logging` from `1.2.0` to `1.3.0`.
Here's what seems to happen:
* `flutter update-packages` will update
`dev/integration_tests/link_hook/pubspec.yaml` with `package:logging` to
`1.3.0` (as it does with all other `pubspec.yaml` files in the flutter
repository)
* `flutter create --template=package_ffi` will generate a template with
`package:logging` `^1.2.0`
* The test in question
* creates ffi template (which will use `^1.2.0`)
* make it depend on `dev/integration_tests/link_hook` (which uses
`=1.3.0`)
* changes logging dependency from the template from `^1.2.0` to `=1.2.0`
IMHO
* `flutter update-packages` is doing what it's supposed to
* `flutter create --template=package_ffi` can generate templates with
versions it determines (maybe there are use cases where we want to
generate templates with older versions)
* The problematic part is the test:
* it makes the generated template depend on `link_hook` and
* changes template generated pubspec to use pinned dependencies
This PR makes the test package (created via template) use the pinned
package versions from `dev/integration_tests/link_hook` (for
dependencies that are common among the two).
All other dependencies that the template has on top of
`dev/integration_tests/link_hook` it can pin as it does currently.
This will give us deterministic CI behavior (as we use flutter pined
packages and remaining deps being pinned via template) It avoids
changing the `flutter update-packages` and `flutter create
--template=package_ffi` (as their behavior seems reasonable)
Should fix https://github.com/flutter/flutter/issues/158135
Closes https://github.com/flutter/flutter/issues/158120.
This PR restores the skipped test, moving it (and the test utility only used by the test) into a standalone file that can be more easily understood. As part of the change the version of `native_assets_cli` is now derived from the (checked-in) `package_ffi/pubspec.yaml.tmpl`, meaning that it should be hard to get into a bad state again.
/cc @christopherfujino (You are welcome to review, but otherwise will defer to Brandon and Victor).
Two of the tests, `test_test` and `break_on_framework_exceptions`, no longer appear to leak (without changes). Perhaps underlying infrastructure has changed, or some other bug in the tool itself was fixed in meantime.
`packages_test` required resetting `Cache.flutterRoot`.
Work towards https://github.com/flutter/flutter/issues/85160.
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
The nativeAssetDir is not flavor specific and it should only be added to the jniLibs.scrDir once.
Fixes https://github.com/flutter/flutter/issues/155038
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
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)
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.)
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
