flutter run (#181542)
Since https://github.com/flutter/flutter/pull/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 (https://github.com/flutter/flutter/pull/181004#pullrequestreview-3664863551). This PR changes the way the hooks are invoked: * From `flutter run` only run for data assets. (Unblocks https://github.com/flutter/flutter/pull/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 https://github.com/flutter/flutter/pull/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 https://github.com/flutter/flutter/issues/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 https://github.com/flutter/flutter/issues/178529#issuecomment-3542651915, 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.
create_cipd_packages.sh script to allow uploading multiple build-tools versions, and update to new bundle (#179963)
flutter_analyzer_plugin (#175679)" (#179766)
Flutter is Google's SDK for crafting beautiful, fast user experiences for mobile, web, and desktop from a single codebase. Flutter works with existing code, is used by developers and organizations around the world, and is free and open source.
Documentation
For release and other announcements, join the flutter-announce mailing list. Our documentation also tracks breaking changes across releases.
Terms of service
The Flutter tool may occasionally download resources from Google servers. By downloading or using the Flutter SDK, you agree to the Google Terms of Service: https://policies.google.com/terms
For example, when installed from GitHub (as opposed to from a prepackaged
archive), the Flutter tool will download the Dart SDK from Google servers
immediately when first run, as it is used to execute the flutter tool itself.
This will also occur when Flutter is upgraded (e.g. by running the flutter upgrade command).
About Flutter
We think Flutter will help you create beautiful, fast apps, with a productive, extensible and open development model, whether you're targeting iOS or Android, web, Windows, macOS, Linux or embedding it as the UI toolkit for a platform of your choice.
Beautiful user experiences
We want to enable designers to deliver their full creative vision without being forced to water it down due to limitations of the underlying framework. Flutter's layered architecture gives you control over every pixel on the screen and its powerful compositing capabilities let you overlay and animate graphics, video, text, and controls without limitation. Flutter includes a full set of widgets that deliver pixel-perfect experiences whether you're building for iOS (Cupertino) or other platforms (Material), along with support for customizing or creating entirely new visual components.

Fast results
Flutter is fast. It's powered by hardware-accelerated 2D graphics libraries like Skia (which underpins Chrome and Android) and Impeller. We architected Flutter to support glitch-free, jank-free graphics at the native speed of your device.
Flutter code is powered by the world-class Dart programming language, which enables compilation to 32-bit and 64-bit ARM machine code for iOS and Android, JavaScript and WebAssembly for the web, as well as Intel x64 and ARM for desktop devices.

Productive development
Flutter offers stateful hot reload, allowing you to make changes to your code and see the results instantly without restarting your app or losing its state.
Extensible and open model
Flutter works with any development tool (or none at all), and also includes editor plug-ins for both Visual Studio Code and IntelliJ / Android Studio. Flutter provides tens of thousands of packages to speed your development, regardless of your target platform. And accessing other native code is easy, with support for both FFI (on Android, on iOS, on macOS, and on Windows) as well as platform-specific APIs.
Flutter is a fully open-source project, and we welcome contributions. Information on how to get started can be found in our contributor guide.
