- Bumps `vm_service` from `11.6.0` to `11.7.1`
- Bumps `web` from `0.1.3-beta` to `0.1.4-beta` and adds it everywhere.
- Moves `js` from `dependencies` to `dev_dependencies`
Unpins flutter_plugin_android_lifecycle where it is pinned. I then
1. ran `flutter update-packages --force-upgrade` (but only committed the changes within `dev/integration_tests/gradle_deprecated_settings/`, which is where it had been pinned)
2. followed by `./gradlew :generateLockfiles` from `dev/integration_tests/gradle_deprecated_settings/android/` (the lockfile was what was causing the CI dependency resolution failure, so this second step is the fix for that).
See the reason it was pinned: https://github.com/flutter/flutter/pull/121847#discussion_r1124797112 followed by the PR that pinned it: https://github.com/flutter/flutter/pull/122043
Fixes https://github.com/flutter/flutter/issues/122039
## Description
This improves defaults generation with logging, stats, and token validation.
This PR includes these changes:
* introduce `TokenLogger`, with a verbose mode
* prints versions and tokens usage to the console
* outputs `generated/used_tokens.csv`, a list of all used tokens, for use by Google
* find token files in `data` automatically
* hide tokens `Map`
* tokens can be obtained using existing resolvers (e.g. `color`, `shape`), or directly through `getToken`.
* tokens can be checked for existence with `tokenAvailable`
* remove version from template, since the tokens are aggregated and multiple versions are possible (as is the case currently), it does not make sense to attribute a single version
* improve documentation
## Related Issues
- Fixes https://github.com/flutter/flutter/issues/122602
## Tests
- Added tests for `TokenLogger`
- Regenerated tokens, no-op except version removal
## Future work
A future PR should replace or remove the following invalid tokens usages
<img width="578" alt="image" src="https://github.com/flutter/flutter/assets/6655696/b6f9e5a7-523f-4f72-94f9-1b0bf4cc9f00">
Fixes#124252, finishing work on the umbrella tracking issue, #126126.
Essentially, after this PR, no (non-test) code should be be referencing/invoking the java home or binary paths.
Changes `Linux_android flutter_engine_group_performance` to uninstall the app that it uses for testing before attempting to install it again to ensure proper cleanup.
Attempt at fixing https://github.com/flutter/flutter/issues/127011.
By default, the browser fuzzes the timer APIs such that they have a granularity of approximately 100 microseconds (this is due to Spectre mitigation techniques). However, many of the thing we are trying to measure actually have a much finer granularity than 100 microseconds. As a result, many of our benchmarks are extremely noisy and don't provide accurate data.
By serving the initial script files with the `Cross-Origin-Opener-Policy: same-origin` and `Cross-Origin-Embedder-Policy: require-corp` HTTP headers, the browser runs the benchmarks in a `crossOriginIsolated` context, which restores the fine granularity of APIs such as `performance.now()` to microsecond precision.
Also, we were considering anything an outlier that was more than one standard deviation away from the mean. In a normal distribution, that means we are only capturing 68% of the data and the rest are considered outliers. This is not ideal. Doing two standard deviations away captures 95% of the data, and the outliers are in the remaining 5%, which seems much more reasonable.
I think the flake is due to setclipboard or semantics update race condition. I migrated the test to use integration test package which relies less on timing
fixes https://github.com/flutter/flutter/issues/124636
Removes the `null_safety=true` query parameter from DartPad samples in the API docs, since all DartPad channels only support null safety now and the parameter does nothing.
## Test
Removing code, but updates the check in the dartdoc tool for the removal.
## Background
The Windows runner has a race at startup:
1. **Platform thread**: creates a hidden window
2. **Platform thread**: launches the Flutter engine
3. **UI/Raster threads**: renders the first frame
4. **Platform thread**: Registers a callback to show the window once the next frame has been rendered.
Steps 3 and 4 happen in parallel and it is possible for step 3 to complete before step 4 starts. In this scenario, the next frame callback is never called and the window is never shown.
As a result the `windows_startup_test`'s test, which [verifies that the "show window" callback is called](1f09a8662d/dev/integration_tests/windows_startup_test/windows/runner/flutter_window.cpp (L60-L64)), can flake if the first frame is rendered before the show window callback has been registered.
## Solution
This change makes the runner schedule a frame after it registers the next frame callback. If step 3 hasn't completed yet, this no-ops as a frame is already scheduled. If step 3 has already completed, a new frame will be rendered, which will call the next frame callback and show the window.
Part of https://github.com/flutter/flutter/issues/119415
See this thread for alternatives that were considered: https://github.com/flutter/engine/pull/42061#issuecomment-1550080722
Removes two plugin tests that aren't actually doing anything useful.
When they were added they were testing v2-embedding plugins in a v1-embedding app, but support for creating v1-embedding apps--and the environment variable that these tests were using to, in theory, trigger them--was removed several years ago in #61203. That means that these tests are in practice exact duplicates of the copies just above without the ennvironment variables.
Fixes https://github.com/flutter/flutter/issues/122200
Sync lints with https://github.com/dart-lang/linter/blob/master/example/all.yaml and enable `implicit_reopen` and `type_literal_in_constant_pattern` (which have no violations). Also contains some clean-up work towards enabling `matching_super_parameters`, which is not quite ready yet due to its handling of "private" arguments.
Fixes#122250. This PR is to make sure all the MaterialStateProperty defaults are able to correctly resolve different states.
* When a widget is pressed, it is also hovered, so we need to put the `MaterialState.pressed` check before `MaterialState.hovered`.
* When a widget is focused, the widget should still be able to be hovered, so we should check `MaterialState.hovered` before `MaterialState.focused`.
* There are also cases like in _InputDecoratorDefaultsM3, the `MaterialState.disabled` should be checked before `MaterialState.error`.
the order should be disabled, (error), pressed, hovered, focused.
