Fix the `--ab` option in the benchmark harness:
- Make `--local-engine-host` optional. The web engine doesn't need it, so it doesn't build it. But the tool crashes by failing to find it.
- Disable icon tree shaking because `--ab` runs against local engine build, whose Dart kernel version is out of sync with the framework, which crashes the const finder.
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
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
**Three things**
Re-lands #154374
New: fix `platform_channels_benchmarks` to print the "done" key. Updated notes for the microbenchmark parser. There are no other users of `microbenchmarks.readJsonResults`.
Re-Re-land: Uninstall microbenchmarks before running them.
Flakes in https://github.com/flutter/flutter/issues/153828 stem from adb saying the app isn't installed, but then failing to install wtih -r. Several other tests uninstall the app before trying to run it. Previous fix called uninstall between tests, but iOS takes 12 to 13 seconds to perform uninstall / install, which timed out the test. Just uninstall the one time since we only care about any lingering apps with different keys.
Potential solution https://github.com/flutter/flutter/issues/153828
Re-land Make things go fast
Instead of installing 21 different compilations of the same app to get results; compile and run them together. Locally on Mac+iOS, this should takes ~3 minutes instead of ~15 minutes.
Reverts: flutter/flutter#154374
Initiated by: jtmcdole
Reason for reverting: A different benchmark was using the microbenchmark parser and timing out.
Original PR Author: jtmcdole
Reviewed By: {zanderso}
This change reverts the following previous change:
Two things:
**Re-land**: Uninstall microbenchmarks before running them.
Flakes in #153828 stem from adb saying the app isn't installed, but then failing to install wtih `-r`. Several other tests uninstall the app before trying to run it. Previous fix called uninstall between tests, but iOS takes 12 to 13 seconds to perform uninstall / install, which timed out the test. Just uninstall the one time since we only care about any lingering apps with different keys.
Potential solution #153828
**Make things go fast**
Instead of installing 21 different compilations of the same app to get results; compile and run them together. Locally on Mac+iOS, this should takes ~3 minutes instead of ~15 minutes.
Two things:
**Re-land**: Uninstall microbenchmarks before running them.
Flakes in #153828 stem from adb saying the app isn't installed, but then failing to install wtih `-r`. Several other tests uninstall the app before trying to run it. Previous fix called uninstall between tests, but iOS takes 12 to 13 seconds to perform uninstall / install, which timed out the test. Just uninstall the one time since we only care about any lingering apps with different keys.
Potential solution #153828
**Make things go fast**
Instead of installing 21 different compilations of the same app to get results; compile and run them together. Locally on Mac+iOS, this should takes ~3 minutes instead of ~15 minutes.
Reverts: flutter/flutter#154183
Initiated by: zanderso
Reason for reverting: microbenchmarks timing out on CI.
Original PR Author: jtmcdole
Reviewed By: {andrewkolos}
This change reverts the following previous change:
Flakes in #153828 stem from adb saying the app isn't installed, but then failing to install wtih `-r`. Several other tests uninstall the app before trying to run it.
Potential corrects #153828
Flakes in #153828 stem from adb saying the app isn't installed, but then
failing to install wtih `-r`. Several other tests uninstall the app
before trying to run it.
Potential corrects #153828
A recent change to the flutter_drone recipe is setting FLUTTER_TEST_OUTPUTS_DIR in the environment (see https://flutter.googlesource.com/recipes/+/b111cd3ef2297e66905cc48c2cfedce0cf1ba46f)
If FLUTTER_TEST_OUTPUTS_DIR is set, then perf_tests will use an output path based on that variable. perf_tests_test needs to use the same logic when looking for the expected output file.
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).
This test expects to run on 32-bit hardware, but the devicelab no longer
has 32-bit Android hardware. In particular, the test contains hand-coded
32-bit arm assembly for reading the stack pointer from Dart code via
`dart:ffi`.
This test was added in response to a framework change that caused stack
frames to be larger than expected while building widgets, leading apps
to crash with StackOverflow exceptions unexpectedly. Since then (>3
years ago) this test has not prevented any similar issue, so I believe
deleting it rather than fixing it is a better use of resources.
As in https://github.com/flutter/flutter/pull/152696, It's not clear
that DDS initialization is necessary for any of these tests.
In particular, from the comments on the tool flag:
```
'It may be necessary to disable this when attaching to an application with '
'an existing DDS instance (e.g., attaching to an application currently '
'connected to by "flutter run"), or when running certain tests.\n'
'Disabling this feature may degrade IDE functionality if a DDS instance is '
'not already connected to the target application.'
```
These tests are unlikely to need IDE functionality. I have initially
modified the Linux_android_emu tests in the ci.yaml so that they run in
presubmit to verify that this change is safe. Many other postsubmit-only
tests that will now be passed `--no-dds` require physical devices, and
if there is an issue in post-submit, this change will need to be
reverted.
Sets up tests that verify we can build a fresh counter app across our Gradle/AGP/Kotlin support range.
Post submit only, because the suite takes ~30 minutes to run, and I expect it to be _somewhat_ rare that we break only one of these versions (and therefore it doesn't get caught by existing presubmits).
Even though we haven't completed the process of removing the Skia backend, its unlikely that we will target changes to the picture/ayer cache system or investigate changes in these values that don't also result in raster time changes.
Remove to reduce noise in Skia Perf.
Part of https://github.com/flutter/flutter/issues/143532
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
This is a very common usage of ad so we want to make sure it's performant.
From the video, it scrolls quite smoothly, but we want to see the numbers, and keep monitoring it in case of regression.
https://github.com/flutter/flutter/assets/41930132/c7811c15-ac07-4989-a8a9-3c128e08cbe0
*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.*
Fixes https://github.com/flutter/flutter/issues/150230
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Some performance tests run "flutter create" to generate platform-specific project configuration files for the test app. These files may be further patched by the test script to apply settings such as the Impeller backend.
The manifests need to be deleted and recreated on each run so that settings applied by previous runs will not be used by the current run.
Fixes https://github.com/flutter/flutter/issues/150093
New tests added to cover that we at least pass the arguments we expect to adb.
The test for #150093 is not ideal in that it does not verify the behavior of a failed process but instead ensures we set the parameter that contains the behavior we want.
devicelab code and tests are not setup to enable fake process or fake output from stdin/stderr and hang if adb or no hardware are present.
Initial tap is missing sometimes; either its never delivered or it is
delivered before gesture controller is hooked up.
1: Update MemoryTest to have option `requiresTapToStart` guarding the
new paths
2: Update the two perf tests that appear to be flaky to output when
TAPPED is received
3: Update the MemoryTest to keep tapping while waiting for TAPPED
Tested on devicelab:
* setting iterations=1
* removing the timeout before READY
* running tests in a while loop
Before this change, you could get the test to hang often. After this
change you'll see "tapping device... [x]" where x is the counter.
Fixes https://github.com/flutter/flutter/issues/150096
Reverts: flutter/flutter#150287
Initiated by: jtmcdole
Reason for reverting: other memperf tests don't wait for or send a TAPPED; so they fail.
Original PR Author: jtmcdole
Reviewed By: {gaaclarke}
This change reverts the following previous change:
Initial tap is missing sometimes; either its never delivered or it is delivered before gesture controller is hooked up.
1: Update the two perf tests to output when TAPPED is received
2: Update the MemoryTest to keep tapping while waiting for TAPPED
Tested on devicelab:
* setting iterations=1
* removing the timeout before READY
* running tests in a while loop
Before this change, you could get the test to hang often. After this change you'll see "tapping device... [x]" where x is the counter.
Fixes#150096
Initial tap is missing sometimes; either its never delivered or it is delivered before gesture controller is hooked up.
1: Update the two perf tests to output when TAPPED is received
2: Update the MemoryTest to keep tapping while waiting for TAPPED
Tested on devicelab:
* setting iterations=1
* removing the timeout before READY
* running tests in a while loop
Before this change, you could get the test to hang often. After this change you'll see "tapping device... [x]" where x is the counter.
Fixes#150096
