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.
Removes these two discontinued plugins from `dev/integration_tests/flutter_gallery`
[`device_info`](https://pub.dev/packages/device_info):
Apparently the video playback doesn't work on iOS simulators (I wasn't able to verify this, as I don't have an iOS simulator installed). I removed the guard against running on those simulators, and replaced with a note in the README.
[`connectivity`](https://pub.dev/packages/connectivity):
This plugin was used to play the bee video from the network. I changed the demo so that the bee video is instead also played from an asset (like its friend the butterfly), and then removed the use of the plugin.
Unblocks the re-land of https://github.com/flutter/engine/pull/53462 (itself a reland ð), because of https://github.com/flutter/flutter/pull/150465#issuecomment-2181403712.
PR to pave the way for https://github.com/flutter/engine/pull/53001 to re-land
Summary:
- Enforces use of Kotlin >= `1.7.0` (please see below note)
- Fixes ci failures that prevented the above PR from landing.
Details:
Because it landed initially, we are able to fake the roll in this PR to fix all the tests ([see my comment](https://github.com/flutter/flutter/pull/149204#discussion_r1617924772)).
Fixes all the tests that failed:
1. `module_test` failing on multiple platforms (3/9 of the failures).
Failure is
```
> Android resource linking failed
ERROR:/b/s/w/ir/x/t/flutter_module_test.KECMXW/hello/.android/plugins_build_output/device_info/intermediates/merged_res/release/values/values.xml:194: AAPT: error: resource android:attr/lStar not found.
```
This is a rather unhelpful error message but some [folks online suggest](https://stackoverflow.com/a/69050529) that upgrading your `compileSdk` version fixes this.
These resolve when I remove the dependency on the long discontinued [package_info](https://pub.dev/packages/package_info) and [device_info](https://pub.dev/packages/device_info) packages, perhaps because they are transitively pulling in low `compileSdk` versions? This is unclear to me.
2. `module_custom_host_app_name_test` was failing for the same reason (another 3/9, or cumulative 6/9).
3. `tool_integration_tests_3_4` was a flake ð (7/9)
4. `framework_tests_slow` needed a newer version of the Kotlin Gradle plugin (the flutter tool tells us this, so I just upgraded as suggested) and it resolved (8/9)
5.`android_preview_tool_integration_tests` needed newer AGP and KGP versions. I also refactored the tests, and bumped our error versions, fixing https://github.com/flutter/flutter/issues/142653.
**Note that the bump to KGP is not in line with our policy** - we didn't warn for `1.5.0-1.6.x` for a release (or at all) before dropping support. But I think it might still be justified:
- The bump to our androidx libraries unblocks ongoing Scribe work, and also includes a fix for a [memory leak](https://github.com/flutter/flutter/issues/129307#issuecomment-1601636959) and a [crash on folding phones](https://github.com/flutter/flutter/issues/114868#issuecomment-2133226962), among many other bug fixes.
- Gradle [doesn't test on half of that range](https://docs.gradle.org/current/userguide/compatibility.html#kotlin), and so we implicitly can't claim to support it either. More generally, our Java and Kotlin support ranges should probably strictly fall within what Gradle tests.
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
Unpin `archive` version and run `flutter update-packages --force-upgrade` to show there are no additional dependencies pulled in (url_launcher was updated, but unrelated).
Fixes https://github.com/flutter/flutter/issues/149427
Manual recreation of https://github.com/flutter/flutter/pull/148911
Entire PR is just the output of
```
flutter update-packages --force-upgrade
```
followed by (run from the root of the flutter repo)
```
find . -type d -name 'android' | dart dev/tools/bin/generate_gradle_lockfiles.dart --no-gradle-generation --no-exclusion
```
This PR is step 12 in the journey to solve issue #136139 and make the
entire Flutter repo more readable.
Most of it involves implementing switch expressions, and there's also a
few other random things that I wanted to clean up a bit.
This benchmark illustrates the impact that const'ness has on widget build times by building a widget tree with all const-widgets and then building the same widget tree without any const'ness. Local testing with this benchmark running on a Moto G4 shows that const'ness is 13-16% faster.
I'd like to check this benchmark in because the question of how important widget const'ness is comes up every so often. With this benchmark we have up-to-date data to point people to.
DDS was temporarily pinned to 4.1.0 because 4.2.0 triggered some test
failures (see https://github.com/flutter/flutter/pull/147250). Those
failures should be fixed by vm_service 14.2.2, so this unpins DDS and
rolls both of these packages (along with devtools_shared, which is a DDS
dependency).
(If the bot updates vm_service before this is done, I can rebase over
that will reduce the size of this PR to just a few files)
## Description
This introduces a list of packages that we will explicitly not pin. It is to be used for things where the package isn't actually published, but is a transitive dependency of another package included in the SDK. This happens with the `macros` package, for instance, which depends on the private, unpublished, `_macros` package where the SDK does some tricky things to depend on it (it depends on "any", but ships it as part of the SDK).
Also ran `flutter update-packages --force-update` to update all of the pubspec files.
## Related Issues
- Fixes#147656
## Tests
- Added a test that makes sure that explicitly unpinned packages don't show up in the pinned list.
