…un` (flutter/flutter#181542)

…un` (flutter/flutter#181542)

…un` (flutter/flutter#181542)

…un` (flutter/flutter#181542)

…un` (flutter/flutter#181542)

Roll Flutter from da72d5936d69 to 1d9d6a9a5ef6 (33 revisions)

flutter/flutter@da72d59...1d9d6a9

2026-01-30 [email protected] enable enhanced debugging for GLES playground (flutter/flutter#181157)
2026-01-30 [email protected] Make the Windows windowing_test in .ci.yaml have bringup as false (flutter/flutter#181664)
2026-01-30 [email protected] Roll Packages from cd4fd61 to 510dd40 (4 revisions) (flutter/flutter#181726)
2026-01-30 [email protected] Roll Skia from edbf7e9eb846 to 4745eb2fe837 (1 revision) (flutter/flutter#181725)
2026-01-30 [email protected] Enhance error handling of WidgetsBindingObserver callbacks (flutter/flutter#181174)
2026-01-30 [email protected] Roll Skia from 05d3cb9d2be9 to edbf7e9eb846 (2 revisions) (flutter/flutter#181715)
2026-01-30 [email protected] Roll Skia from c198e5fa9cd9 to 05d3cb9d2be9 (1 revision) (flutter/flutter#181712)
2026-01-30 [email protected] Roll Dart SDK from 920b7e24583e to 2703fd9733ce (2 revisions) (flutter/flutter#181693)
2026-01-30 [email protected] Roll Skia from b9f40c193e7a to c198e5fa9cd9 (6 revisions) (flutter/flutter#181692)
2026-01-30 [email protected] Roll pub packages (flutter/flutter#181690)
2026-01-30 [email protected] Extend the Windows tool_integration_tests_2_9 shard timeout to 1 hour (flutter/flutter#181678)
2026-01-29 [email protected] Add `android_sdk` dependency to `android_engine_opengles_tests` (flutter/flutter#181681)
2026-01-29 [email protected] Roll Dart SDK from a0685c8e946b to 920b7e24583e (3 revisions) (flutter/flutter#181680)
2026-01-29 [email protected] Roll Skia from 128b5213711e to b9f40c193e7a (14 revisions) (flutter/flutter#181675)
2026-01-29 [email protected] [Impeller] Ensure that HostBuffers/DeviceBuffers allocated by RendererTest tests are valid for the lifetime of the RenderPass (flutter/flutter#181635)
2026-01-29 [email protected] [Impeller] Fix off-by-one indices in the SimilarPointPair/SimilarPointTrio functions used by ShadowPathGeometryTest (flutter/flutter#181623)
2026-01-29 [email protected] 180162 fix radio list tile and switch list tile accept widget states controller (flutter/flutter#180367)
2026-01-29 [email protected] Remove unused test file (flutter/flutter#181671)
2026-01-29 [email protected] Roll libpng to version 1.6.54 (flutter/flutter#181625)
2026-01-29 [email protected] Remove nonstandard ndkpath for `hybrid_android_views` integration test (flutter/flutter#181666)
2026-01-29 [email protected] Add TestWidgetsApp utility and refactor widget tests to use WidgetsApp (flutter/flutter#180456)
2026-01-29 [email protected] Add `TestTextField` and migrate tests (flutter/flutter#180494)
2026-01-29 [email protected] Merge changelog for 3.38.9 (flutter/flutter#181668)
2026-01-29 [email protected] [flutter_tools] Deprecate `plugin_ffi` template (flutter/flutter#181588)
2026-01-29 [email protected] Deprecate onReorder callback (flutter/flutter#178242)
2026-01-29 [email protected] [web] Use defensive null check in text editing placeElement (flutter/flutter#180795)
2026-01-29 [email protected] Roll Packages from 1cb2148 to cd4fd61 (4 revisions) (flutter/flutter#181663)
2026-01-29 [email protected] Roll Skia from 89df65f8324c to 128b5213711e (2 revisions) (flutter/flutter#181651)
2026-01-29 [email protected] [hooks] Don't run build hooks for code assets in `flutter run` (flutter/flutter#181542)
2026-01-29 [email protected] Roll Dart SDK from f10dcbfca98f to a0685c8e946b (5 revisions) (flutter/flutter#181653)
2026-01-29 [email protected] Fixes getUniformX for Vulkan (flutter/flutter#181286)
2026-01-29 [email protected] Roll Fuchsia Linux SDK from adhoq9ouVRh0xzkm3... to isy1ARvK-3bsvtfc-... (flutter/flutter#181641)
2026-01-29 [email protected] Add isDark, isLight, and isSystem getters to ThemeMode (flutter/flutter#181475)

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-packages
Please CC [email protected],[email protected] on the revert to ensure that a human
is aware of the problem.

To file a bug in Packages: https://github.com/flutter/flutter/issues/new/choose

To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622

Documentation for the AutoRoller is here:
...

…er#181542)

Since flutter#174685, the code assets
are wrongly invoked on in the `flutter run` process (in addition to
rightly in the `flutter assemble` process). This should not be the case:
We don't know the target architectures we want to build for, neither do
we know which native compiler is set by the native build system that is
invoking us
(flutter#181004 (review)).

This PR changes the way the hooks are invoked:

* From `flutter run` only run for data assets. (Unblocks
flutter#181004)
* All other remaining calls, run for both. There might be locations
where data assets could be disabled, but they are needed from the
`DartBuild` target at least in some cases.

The architecture becomes as follows:

* `FlutterNativeAssetsBuildRunner` this is basically the wrapper around
the `NativeAssetsBuildRunner` and there should be only one in a
`flutter_tools` instance, unchanged.
* `FlutterHookRunner` seems to be an interface to be able to supply
fakes, unchanged.
* `runFlutterSpecificHooks` get bool arguments whether they should build
code assets and data assets.
* The callers of these APIs know what asset types are needed in that
context. The invocations added in
flutter#174685 should be data assets
only.
* Simplification: `FlutterHookRunnerNative.runHooks` does no longer use
`globals.buildSystem.build`. Instead, it directly calls
`runFlutterSpecificHooks`.
* This completely avoids writing to the flutter build directory, which
was the cause of flutter#178529.
* The `ProtocolExtension`s (which determine which asset types are built)
are taken from `AssetBuildTarget`s, and take into account what asset
types to build, unchanged.

Tests:

* Code assets covered by existing integration tests such as
packages/flutter_tools/test/integration.shard/isolated/native_assets_test.dart
* Data assets covered by existing integration tests such as
packages/flutter_tools/test/integration.shard/isolated/dart_data_asset_test.dart
* This PR completely deletes
packages/flutter_tools/test/general.shard/build_system/targets/hook_runner_native_test.dart.
It was a unit test that testsed the specific workaround, not the effect
of the workaround.
* I've manually tested the steps in
flutter#178529 (comment),
the issue does not come back.
  
> the underlying issue did involve conflict between state written by the
original run of the build system versus state written by the secondary
run executed for the data assets. If the secondary run can be avoided,
then that seems cleaner.

Yep, removed.

…er#181542)

Since flutter#174685, the code assets
are wrongly invoked on in the `flutter run` process (in addition to
rightly in the `flutter assemble` process). This should not be the case:
We don't know the target architectures we want to build for, neither do
we know which native compiler is set by the native build system that is
invoking us
(flutter#181004 (review)).

This PR changes the way the hooks are invoked:

* From `flutter run` only run for data assets. (Unblocks
flutter#181004)
* All other remaining calls, run for both. There might be locations
where data assets could be disabled, but they are needed from the
`DartBuild` target at least in some cases.

The architecture becomes as follows:

* `FlutterNativeAssetsBuildRunner` this is basically the wrapper around
the `NativeAssetsBuildRunner` and there should be only one in a
`flutter_tools` instance, unchanged.
* `FlutterHookRunner` seems to be an interface to be able to supply
fakes, unchanged.
* `runFlutterSpecificHooks` get bool arguments whether they should build
code assets and data assets.
* The callers of these APIs know what asset types are needed in that
context. The invocations added in
flutter#174685 should be data assets
only.
* Simplification: `FlutterHookRunnerNative.runHooks` does no longer use
`globals.buildSystem.build`. Instead, it directly calls
`runFlutterSpecificHooks`.
* This completely avoids writing to the flutter build directory, which
was the cause of flutter#178529.
* The `ProtocolExtension`s (which determine which asset types are built)
are taken from `AssetBuildTarget`s, and take into account what asset
types to build, unchanged.

Tests:

* Code assets covered by existing integration tests such as
packages/flutter_tools/test/integration.shard/isolated/native_assets_test.dart
* Data assets covered by existing integration tests such as
packages/flutter_tools/test/integration.shard/isolated/dart_data_asset_test.dart
* This PR completely deletes
packages/flutter_tools/test/general.shard/build_system/targets/hook_runner_native_test.dart.
It was a unit test that testsed the specific workaround, not the effect
of the workaround.
* I've manually tested the steps in
flutter#178529 (comment),
the issue does not come back.
  
> the underlying issue did involve conflict between state written by the
original run of the build system versus state written by the secondary
run executed for the data assets. If the secondary run can be avoided,
then that seems cleaner.

Yep, removed.

…er#181542)

Since flutter#174685, the code assets
are wrongly invoked on in the `flutter run` process (in addition to
rightly in the `flutter assemble` process). This should not be the case:
We don't know the target architectures we want to build for, neither do
we know which native compiler is set by the native build system that is
invoking us
(flutter#181004 (review)).

This PR changes the way the hooks are invoked:

* From `flutter run` only run for data assets. (Unblocks
flutter#181004)
* All other remaining calls, run for both. There might be locations
where data assets could be disabled, but they are needed from the
`DartBuild` target at least in some cases.

The architecture becomes as follows:

* `FlutterNativeAssetsBuildRunner` this is basically the wrapper around
the `NativeAssetsBuildRunner` and there should be only one in a
`flutter_tools` instance, unchanged.
* `FlutterHookRunner` seems to be an interface to be able to supply
fakes, unchanged.
* `runFlutterSpecificHooks` get bool arguments whether they should build
code assets and data assets.
* The callers of these APIs know what asset types are needed in that
context. The invocations added in
flutter#174685 should be data assets
only.
* Simplification: `FlutterHookRunnerNative.runHooks` does no longer use
`globals.buildSystem.build`. Instead, it directly calls
`runFlutterSpecificHooks`.
* This completely avoids writing to the flutter build directory, which
was the cause of flutter#178529.
* The `ProtocolExtension`s (which determine which asset types are built)
are taken from `AssetBuildTarget`s, and take into account what asset
types to build, unchanged.

Tests:

* Code assets covered by existing integration tests such as
packages/flutter_tools/test/integration.shard/isolated/native_assets_test.dart
* Data assets covered by existing integration tests such as
packages/flutter_tools/test/integration.shard/isolated/dart_data_asset_test.dart
* This PR completely deletes
packages/flutter_tools/test/general.shard/build_system/targets/hook_runner_native_test.dart.
It was a unit test that testsed the specific workaround, not the effect
of the workaround.
* I've manually tested the steps in
flutter#178529 (comment),
the issue does not come back.
  
> the underlying issue did involve conflict between state written by the
original run of the build system versus state written by the secondary
run executed for the data assets. If the secondary run can be avoided,
then that seems cleaner.

Yep, removed.