Reverts: flutter/flutter#156440
Initiated by: zanderso
Reason for reverting: Failing in post submit with
```
[2024-10-08 18:00:22.743647] [STDOUT] stdout: [!] CocoaPods could not find compatible versions for pod "Google-Mobile-Ads-SDK":
[2024-10-08 18:00:22.743695] [STDOUT] stdout: In Podfile:
[2024-10-08 18:00:22.743718] [STDOUT] stdout: google_mobile_ads (from `.symlinks/plugins/google_mobile_ads/ios`) was resolved t
Original PR Author: flutter-pub-roller-bot
Reviewed By: {fluttergithubbot}
This change reverts the following previous change:
This PR was generated by `flutter update-packages --force-upgrade`.
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)
Prior to this fix, `_TaskRunner.run` would immediately cleanup the
keep-alive port once the task completed, which would result in the
isolate shutting down as soon as the task result was returned from
`ext.cocoonRunTask` callback in the form of a
`ServiceExtensionResponse`. Since the service extension response is
processed by the service isolate, it was possible for the VM to start
shutting down before the service isolate could send the task result data
back to the task runner.
This change introduces a new service extension,
`ext.cocoonTaskResultReceived`, that the task runner invokes after it
receives the task result from `ext.cocoonRunTask`, notifying the task
process that it can close the keep-alive port and shutdown.
Fixes https://github.com/flutter/flutter/issues/155475
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
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Fixes another invocation of `flutter`. Follow up to https://github.com/flutter/flutter/pull/155790/.
Checked that this is the only other one (and also the only use of `exec()` left that is relying on the path and shouldn't be (one other use uses git from the path, which is fine, and the other one uses an absolute path).
Reverts: flutter/flutter#155476
Initiated by: eyebrowsoffire
Reason for reverting: The newly added tests are failing in postsubmit. See https://ci.chromium.org/ui/p/flutter/builders/prod/Windows%20framework_tests_libraries/19062/overview
Original PR Author: QuncCccccc
Reviewed By: {TahaTesser}
This change reverts the following previous change:
This PR is to make preparations to make `TabBarTheme` conform to Flutter's conventions for component themes:
* Added a `TabBarThemeData` class which defines overrides for the defaults for `TabBar` properties.
* Added 2 `TabBarTheme` constructor parameters: `TabBarThemeData? data` and `Widget? child`. This is now the preferred way to configure a `TabBarTheme`:
```
TabBarTheme(
data: TabBarThemeData(labelColor: xxx, indicatorColor: xxx, ...),
child: TabBar(...)
)
```
These two properties are made nullable to not break existing apps which has customized `ThemeData.tabBarTheme`.
* Changed the type of component theme defaults from `TabBarTheme` to `TabBarThemeData`.
TODO:
* Fix internal failures.
* Change the type of `ThemeData.tabBarTheme` from `TabBarTheme` to `TabBarThemeData`. This may cause breaking changes, a migration guide will be created.
Addresses the "theme normalization" sub project within https://github.com/flutter/flutter/issues/91772
This PR is to make preparations to make `TabBarTheme` conform to Flutter's conventions for component themes:
* Added a `TabBarThemeData` class which defines overrides for the defaults for `TabBar` properties.
* Added 2 `TabBarTheme` constructor parameters: `TabBarThemeData? data` and `Widget? child`. This is now the preferred way to configure a `TabBarTheme`:
```
TabBarTheme(
data: TabBarThemeData(labelColor: xxx, indicatorColor: xxx, ...),
child: TabBar(...)
)
```
These two properties are made nullable to not break existing apps which has customized `ThemeData.tabBarTheme`.
* Changed the type of component theme defaults from `TabBarTheme` to `TabBarThemeData`.
TODO:
* Fix internal failures.
* Change the type of `ThemeData.tabBarTheme` from `TabBarTheme` to `TabBarThemeData`. This may cause breaking changes, a migration guide will be created.
Addresses the "theme normalization" sub project within https://github.com/flutter/flutter/issues/91772
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.)
The tool currently prints that the _dart_ command is run, and does not include the 'pub' sub-command. Something like:
```none
/private/var/folders/72/ltck4q353hsg3bn8kpkg7f84005w15/T/flutterzXpww6/bin/dart \
global run --enable-asserts dartdoc
```
(newline mine)
But this is incorrect; the `runPubGet` function runs the _flutter_ command, and prepends `pub` to the list of arguments.
Rework on the text button use case to pass [b/347102786](https://b.corp.google.com/347102786),
After talking with the tester, it seems like there isn't an issue with the A11y of the text button, rather just how the test case is set up. In order for the text case to pass, there needs to be real time feedback of an action that is done by pressing the text button (think of a dialog popup, or form submission notification).
So I rewrote the test case to mimic a simple form with a submit button that once submitted, will let the user know it is submitted with a snack bar notification. https://screencast.googleplex.com/cast/NTM0ODc1NDIxMDE2MDY0MHwzYWI4MTZhMS1hMA
Recently the microbenchmarks were flakey, but from an older bug. Turns out, `LiveTestWidgetsFlutterBindingFramePolicy` is defaulted to `fadePointers` with this fun note:
> This can result in additional frames being pumped beyond those that
the test itself requests, which can cause differences in behavior
Both `text_intrinsic_bench` and `build_bench` use a similar pattern:
* Load stocks app
* Open the menu
* Switch to `benchmark` frame policy
What happens, rarely, is that
`LiveTestWidgetsFlutterBinding.pumpBenchmark()` will call (async) `handleBeginFrame` and `handleDrawFrame`. `handleDrawFrame` juggles a tri-state boolean (null, false, true). This boolean is only reset to `null` when handleDrawFrame is called back to back, say, from an extra frame that was scheduled.
1. Switch tri-state boolean to an enum, its easier to read
2. remove asserts that compile away in benchmarks (`--profile`)
3. use `Error.throwWithStackTrace` to keep stack traces.
I've been running this test on device lab hardware for hundreds of runs and have not hit a failure yet.
Fixes#150542Fixes#150543 - throw stack!
Part 1/n #154724
## 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].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
---------
Co-authored-by: Tirth <pateltirth454@gmail.com>
Co-authored-by: Navaron Bracke <brackenavaron@gmail.com>
https://github.com/flutter/flutter/pull/151675 bumped module templates to AGP 8.1.
In doing so, I tried to work around a behavior change [that was new in AGP 8.0](https://developer.android.com/build/releases/past-releases/agp-8-0-0-release-notes):
> AGP 8.0 creates no SoftwareComponent by default. Instead AGP creates SoftwareComponents only for variants that are configured to be published using the publishing DSL.
by using AGP's publishing DSL to define which variants to publish in the module's ephemeral gradle files:
```
android.buildTypes.all {buildType ->
if (!android.productFlavors.isEmpty()) {
android.productFlavors.all{productFlavor ->
android.publishing.singleVariant(productFlavor.name + buildType.name.capitalize()) {
withSourcesJar()
withJavadocJar()
}
}
} else {
android.publishing.singleVariant(buildType.name) {
withSourcesJar()
withJavadocJar()
}
}
}
```
The problem is that this doesn't get applied to the plugin projects used by the module, so if a module uses any plugin it breaks. This PR fixes that by applying similar logic, but to each project (not just the module's project).
Tested manually with https://github.com/gmackall/GrayAddToApp, and also re-enabled an old test that tested this use case as a part of the PR.
Fixes: https://github.com/flutter/flutter/issues/154371
This PR is _almost_ able to close issue #89127.
Sadly, no `InheritedModel` or custom `RenderObject`s today; instead the [WidgetState operators](https://main-api.flutter.dev/flutter/widgets/WidgetStateOperators.html) have been restructured to support equality checks.
`WidgetStateProperty.fromMap()` is now capable of accurate equality checks, and all of the `.styleFrom()` methods have been refactored to use that constructor.
(Equality checks are still broken for `WidgetStateProperty.resolveWith()`, and any other non-`const` objects that implement the interface.)
<br><br>
credit for this idea goes to @justinmc: https://github.com/flutter/flutter/issues/89127#issuecomment-2313187703
This PR is to make preparations to make `DialogTheme` conform to Flutter's conventions for component themes:
* Added a `DialogThemeData` class which defines overrides for the defaults for `Dialog` properties.
* Added 2 `DialogTheme` constructor parameters: `DialogThemeData? data` and `Widget? child`. This is now the preferred way to configure a `DialogTheme`:
```
DialogTheme(
data: DialogThemeData(color: xxx, elevation: xxx, ...),
child: Dialog(...)
)
```
These two properties are made nullable to not break existing apps which has customized `ThemeData.dialogTheme`.
* Changed the type of theme defaults from `DialogTheme` to `DialogThemeData`.
TODO:
* Fix internal failures.
* Change the type of `ThemeData.dialogTheme` from `DialogTheme` to `DialogThemeData`. This may cause breaking changes, a migration guide will be created.
Addresses the "theme normalization" sub project within https://github.com/flutter/flutter/issues/91772
This updates the codesigning test to account for iOS and macOS binaries in the artifact cache that are _expected_ to not be codesigned.
In https://github.com/flutter/engine/pull/54414 we started bundling dSYM (debugging symbols) within Flutter.xcframework, a requirement for App Store verification using Xcode 16.
We did the same for macOS in https://github.com/flutter/engine/pull/54696.
Unlike the framework dylib, dSYM contents are not directly codesigned (though the xcframework containing them is).
Issue: https://github.com/flutter/flutter/issues/154571
This PR is to update the token version to v6.1.
* This version fixes https://github.com/flutter/flutter/issues/153271
* Change the chip default border color from `ColorScheme.outline` to `ColorScheme.outlineVariant`. The Chips' border color is softened to improve visual hierarchy between chips and buttons
