These warnings/errors have been removed from dartdoc. Removing them from the flutter config as well.
Also fixes CI to actually test doc generation for all documented packages and on dartdoc config changes.
Unmarking this test as flaky in favor of a fix for the [underlying issue](https://github.com/flutter/flutter/issues/135035). None of the other impacted tests have been marked as flaky, so I think it is better for this one to not be treated differently.
I've been keeping an eye on the device list, and android 14 devices recently became available. For reviewing purposes (and anyone who comes across this in the future), you can check the available devices here at the third option without needing a firebase login:
https://firebase.google.com/docs/test-lab/android/available-testing-devices
The "shiba" device is high capacity. There are no api 34 virtual devices yet.
Reenable the NexusLowRes API version 29 tests.
*List which issues are fixed by this PR. You must list at least one issue.*
fixes https://buganizer.corp.google.com/issues/302753598fixesflutter/flutter#135784
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
*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.*
*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 tests have been running on devicelab bots with iOS devices attached, however, they don't require an iOS device. So moving them to run on bots without iOS devices.
Fixes https://github.com/flutter/flutter/issues/136415.
This switches over to using Chrome for Testing instead of Chromium. This should ensure that we are consistently using an official and consistent build of Chrome on all platforms, rather than whatever we can get from the continuous builds archive, which can potentially put platforms out of sync with each other.
This removes the `Windows_arm64 plugin_test` as Devicelab tests aren't able to target Android from a Windows Arm64 host yet. I opened https://github.com/flutter/flutter/issues/136378 to track this work.
In the past I switched the implementation of the zoom page transition because the performance of the old transition was terrible, but I'm hopeful that with Impeller we'll be able to identify and fix the issues that made it so slow. In order to evaluate this though, we need to be able to opt into the old transition for benchmarks on CI.
https://github.com/flutter/flutter/issues/129742https://github.com/flutter/flutter/issues/121325
Part of: https://github.com/flutter/flutter/issues/129806
Test runs kicked off using `led`:
* â [plugin_test_windows](277ffb2c7b/+/build.proto)
* â ï¸ [plugin_test](c9daccd5b3/+/build.proto) - This test fails as no existing Windows Arm64 builder install the `android_sdk` and `open_jdk` dependencies
I will add `plugin_dependencies_test` and `gradle_plugin_bundle_test` in a follow-up pull request. These tests also depend on `android_sdk` and `open_jdk`, I'll be able to test them manually using the new `plugin_test` builder added by this pull request.
/cc @pbo-linaro
There are too many flakes to leave this version enabled. Temporarily disabled and following up with FTL.
*List which issues are fixed by this PR. You must list at least one issue.*
Related to https://github.com/flutter/flutter/issues/135784
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Window arm64 bots are using x64 built python, which gave incorrect arch info. This PR adds the arch info explicitly so that recipes can get this value and populate to benchmark tags.
Part of https://github.com/flutter/flutter/issues/135722
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Linux_android platform_channels_benchmarks"
}
-->
Issue link: https://github.com/flutter/flutter/issues/135105
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Linux_android flutter_gallery__start_up_delayed"
}
-->
Issue link: https://github.com/flutter/flutter/issues/134631
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Linux_android opacity_peephole_grid_of_alpha_savelayers_perf__e2e_summary"
}
-->
Issue link: https://github.com/flutter/flutter/issues/135118
The Github token was recreated and uploaded to GCS. I have verified a passing run with the new key here:
bc5d1e6662/+/build.proto
And the bot is now generating pull requests: https://github.com/flutter/flutter/pull/135315
*List which issues are fixed by this PR. You must list at least one issue.*
Fixes https://github.com/flutter/flutter/issues/131968
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Reland of #134031. (Reverted in #135069.) Contains the fix for b/301051367 together with cl/567233346.
Support for FFI calls with `@Native external` functions through Native assets on Linux. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for Linux.
Mainly follows the design of https://github.com/flutter/flutter/pull/130494.
Some differences are:
* Linux does not support cross compiling or compiling for multiple architectures, so this has not been implemented.
* Linux has no add2app.
The assets copying is done in the install-phase of the CMake build of a flutter app.
CMake requires the native assets folder to exist, so we create it also when the feature is disabled or there are no assets.
### Tests
This PR adds new tests to cover the various use cases.
* packages/flutter_tools/test/general.shard/linux/native_assets_test.dart
* Unit tests the Linux-specific part of building native assets.
It also extends various existing tests:
* packages/flutter_tools/test/integration.shard/native_assets_test.dart
* Runs (incl hot reload/hot restart), builds, builds frameworks for Linux and flutter-tester.
Reverts flutter/flutter#134031
context: b/301051367
Looked at the error message from the broken TAP target, but seems like the failure might be non trivial to resolve. Would it be okay if we revert this for now while it is being triaged?
Support for FFI calls with `@Native external` functions through Native assets on Linux. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for Linux.
Mainly follows the design of https://github.com/flutter/flutter/pull/130494.
Some differences are:
* Linux does not support cross compiling or compiling for multiple architectures, so this has not been implemented.
* Linux has no add2app.
The assets copying is done in the install-phase of the CMake build of a flutter app.
CMake requires the native assets folder to exist, so we create it also when the feature is disabled or there are no assets.
### Tests
This PR adds new tests to cover the various use cases.
* packages/flutter_tools/test/general.shard/linux/native_assets_test.dart
* Unit tests the Linux-specific part of building native assets.
It also extends various existing tests:
* packages/flutter_tools/test/integration.shard/native_assets_test.dart
* Runs (incl hot reload/hot restart), builds, builds frameworks for Linux and flutter-tester.
Xcode uses the CONFIGURATION_BUILD_DIR build setting to determine the location of the bundle to build and install. When launching an app via Xcode with the Xcode debug workflow (for iOS 17 physical devices), temporarily set the CONFIGURATION_BUILD_DIR to the location of the bundle so Xcode can find it.
Also, added a Xcode Debug version of the `microbenchmarks_ios` integration test since it uses `flutter run --profile` without using `--use-application-binary`.
Fixes https://github.com/flutter/flutter/issues/134186.
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Windows module_custom_host_app_name_test"
}
-->
Issue link: https://github.com/flutter/flutter/issues/134644
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Windows_android channels_integration_test_win"
}
-->
Issue link: https://github.com/flutter/flutter/issues/134636
Support for FFI calls with `@Native external` functions through Native assets on MacOS and iOS. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for MacOS and iOS.
Dylibs are bundled by (1) making them fat binaries if multiple architectures are targeted, (2) code signing these, and (3) copying them to the frameworks folder. These steps are done manual rather than via CocoaPods. CocoaPods would have done the same steps, but (a) needs the dylibs to be there before the `xcodebuild` invocation (we could trick it, by having a minimal dylib in the place and replace it during the build process, that works), and (b) can't deal with having no dylibs to be bundled (we'd have to bundle a dummy dylib or include some dummy C code in the build file).
The dylibs are build as a new target inside flutter assemble, as that is the moment we know what build-mode and architecture to target.
The mapping from asset id to dylib-path is passed in to every kernel compilation path. The interesting case is hot-restart where the initial kernel file is compiled by the "inner" flutter assemble, while after hot restart the "outer" flutter run compiled kernel file is pushed to the device. Both kernel files need to contain the mapping. The "inner" flutter assemble gets its mapping from the NativeAssets target which builds the native assets. The "outer" flutter run get its mapping from a dry-run invocation. Since this hot restart can be used for multiple target devices (`flutter run -d all`) it contains the mapping for all known targets.
### Example vs template
The PR includes a new template that uses the new native assets in a package and has an app importing that. Separate discussion in: https://github.com/flutter/flutter/issues/131209.
### Tests
This PR adds new tests to cover the various use cases.
* dev/devicelab/bin/tasks/native_assets_ios.dart
* Runs an example app with native assets in all build modes, doing hot reload and hot restart in debug mode.
* dev/devicelab/bin/tasks/native_assets_ios_simulator.dart
* Runs an example app with native assets, doing hot reload and hot restart.
* packages/flutter_tools/test/integration.shard/native_assets_test.dart
* Runs (incl hot reload/hot restart), builds, builds frameworks for iOS, MacOS and flutter-tester.
* packages/flutter_tools/test/general.shard/build_system/targets/native_assets_test.dart
* Unit tests the new Target in the backend.
* packages/flutter_tools/test/general.shard/ios/native_assets_test.dart
* packages/flutter_tools/test/general.shard/macos/native_assets_test.dart
* Unit tests the native assets being packaged on a iOS/MacOS build.
It also extends various existing tests:
* dev/devicelab/bin/tasks/module_test_ios.dart
* Exercises the add2app scenario.
* packages/flutter_tools/test/general.shard/features_test.dart
* Unit test the new feature flag.
Fixes https://github.com/flutter/flutter/issues/89683.
The changes to `getFlutterView` in `FlutterDeviceScreenshot` are the fix that was required, everything else was done to get tests running (such as re-generating some lockfiles and modifying the android manifest).
The code was all currently not unit tested, and there were no other easy examples to base these java unit tests off in flutter/flutter, so let me know if this approach to testing is wrong.
Adds the first Windows Arm64 devicelab test. The builder for this test won't be created until after this lands on master, so we can't actually test this until this is merged.
Enable Impeller benchmarks for drawAtlas/drawVertices on iOS/Metal, Android/GLES, and Android/Vulkan.
Enable impeller tessellation benchmarks on iOS/Metal and Android/Vulkan - not GLES as this is measuring backend agnostic performance.
Temporarily removes Xcode debug tests.
Xcode tests are currently failing in CI for some infra-related issues. I have a fix for it (https://github.com/flutter/flutter/pull/132318) that I confirmed worked in presubmit, but I think the logic is better suited to live in recipes. However, it's going to be a bit of a learning curve to update recipes and might take me a couple days so disabling them in the meantime.
Tracking issue to readd when ready: https://github.com/flutter/flutter/issues/132309
This PR includes the following changes. These changes only apply to iOS 17 physical devices.
| Command | Change Description | Changes to User Experience |
| ------------- | ------------- | ------------- |
| `flutter run --release` | Uses `devicectl` to install and launch application in release mode. | No change. |
| `flutter run` | Uses Xcode via automation scripting to run application in debug and profile mode. | Xcode will be opened in the background. Errors/crashes may be caught in Xcode and therefore may not show in terminal. |
| `flutter run --use-application-binary=xxxx` | Creates temporary empty Xcode project and use Xcode to run via automation scripting in debug and profile. | Xcode will be opened in the background. Errors/crashes may be caught in Xcode and therefore may not show in terminal. |
| `flutter install` | Uses `devicectl` to check installed apps, install app, uninstall app. | No change. |
| `flutter screenshot` | Will return error. | Will return error. |
Other changes include:
* Using `devicectl` to get information about the device
* Using `idevicesyslog` and Dart VM logging for device logs
Note:
Xcode automation scripting (used in `flutter run` for debug and profile) does not work in a headless (without a UI) interface. No known workaround.
Fixes https://github.com/flutter/flutter/issues/128827, https://github.com/flutter/flutter/issues/128531.
In order to avoid new tasks from not being scheduled we are not going to backfill the autoroller because it can sometimes play transactions out of order causing issues with tasks that are scheduled but not known.
*List which issues are fixed by this PR. You must list at least one issue.*
Part of https://github.com/flutter/flutter/issues/127063
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
I deleted the target mentioned in the issue listed below. This is my first time contributing to open source please explain if I did anything wrong in the process or wrong with the changes.
Best
*List which issues are fixed by this PR. You must list at least one issue.*
Resolves [#126278](https://github.com/flutter/flutter/issues/126278)
Fixes:
- https://github.com/flutter/flutter/issues/131327
It was observed that the tests would hit their 30 minute timeout so this PR adds another shard to reduce how many tests are run per shard to reduce test run time
`ios_app_with_extensions_test` only builds the artifact, it does not need a device to run.
This PR adds the copies of these tests to run hostonly. When the new tests pass in post submit, we should remove the old ones.
We've decided to use the `--omit-type-checks` flag for our dart2wasm benchmarks. Right now, many of the benchmark results are dominated by type checks and most of what we are actually trying to measure get drowned out in the noise.
Alternative to https://github.com/flutter/flutter/pull/130868
Oriole is the Pixel 6, Panther is the Pixel 7. Panther is more available in FTL at this point.
There's less value in running this on presubmit, since those can spawn many jobs multiple times over as people push new commits to branches. Let's just run it post submit to avoid overloading the capacity of FTL.
