It's now possible to natively compile a flutter app for windows-arm64. Cross-compilation is not yet implemented.

Uses arm64 artifacts now available for Dart/Flutter. Platform detection is based on Abi class, provided by Dart. Depending if Dart is an arm64 or x64 binary, the Abi is set accordingly. Initial bootstrap of dart artifacts (update_dart_sdk.ps1) is checking PROCESSOR_ARCHITECTURE environment variable, which is the way to detect host architecture on Windows.

This is available only for master channel (on other channels, it fallbacks to windows-x64).

On windows-x64, it produces an x64 app. On windows-arm64, it produces an arm64 app.

Reverts flutter/flutter#137618
Initiated by: Jasguerrero
This change reverts the following previous change:
Original Description:
It's now possible to natively compile a flutter app for
windows-arm64. Cross-compilation is not yet implemented.

Uses arm64 artifacts now available for Dart/Flutter.
Platform detection is based on Abi class, provided by Dart. Depending if
Dart is an arm64 or x64 binary, the Abi is set accordingly.
Initial bootstrap of dart artifacts (update_dart_sdk.ps1) is checking
PROCESSOR_ARCHITECTURE environment variable, which is the way to detect
host architecture on Windows.

This is available only for master channel (on other channels, it
fallbacks to windows-x64).

On windows-x64, it produces an x64 app. On windows-arm64, it produces an
arm64 app.

It's now possible to natively compile a flutter app for
windows-arm64. Cross-compilation is not yet implemented.

Uses arm64 artifacts now available for Dart/Flutter.
Platform detection is based on Abi class, provided by Dart. Depending if
Dart is an arm64 or x64 binary, the Abi is set accordingly.
Initial bootstrap of dart artifacts (update_dart_sdk.ps1) is checking
PROCESSOR_ARCHITECTURE environment variable, which is the way to detect
host architecture on Windows.

This is available only for master channel (on other channels, it
fallbacks to windows-x64).

On windows-x64, it produces an x64 app. On windows-arm64, it produces an
arm64 app.

To implement windows-arm64 support, it is needed to add architecture as a subdirectory (https://github.com/flutter/flutter/issues/129805).

In short, when performing a flutter windows build, we have:
- Before: build/windows/runner/Release/gallery.exe
- After: build/windows/x64/runner/Release/gallery.exe

This convention follows what flutter linux build does.

Addresses: https://github.com/flutter/flutter/issues/129805
Addresses: https://github.com/flutter/flutter/issues/116196

Design doc: [flutter.dev/go/windows-arm64](https://flutter.dev/go/windows-arm64)

flutter-tool: enum cleanup

Allow flutter run to work end-to-end with a UWP device.

Uses win32/ffi for the actual launch of the application, injected via
the native API class. This is structured to avoid a g3 dependency.

Install and amuid require powershell scripts for now.

Actually connecting to the observatory requires running a command in an
elevated prompt. Instructions are presented to the user if a terminal is
attached.

This is a rebased version of https://github.com/flutter/flutter/pull/79684
by @jonahwilliams, updated to remove `NativeApi` and replace is with calls
to `uwptool`.

Part of https://github.com/flutter/flutter/issues/82085

* opt out the flutter tool

* oops EOF

* fix import

* Update tool_backend.dart

* Update daemon_client.dart

* fix more

* First pass at CMake files; untested

* First pass of adding CMake generation logic on Windows

* Misc fixes

* Get bundling working, start incoprorating CMake build into tool

* Fix debug, exe name.

* Add resources

* Move cmake.dart

* Rip out all the vcxproj/solution plumbing

* Fix plugin cmake generation

* Build with cmake rather than calling VS directly

* Adjust Windows plugin template to match standard header directory structure

* Pass config selection when building

* Partially fix multi-config handling

* Rev template version

* Share the CMake generation instead of splitting it out

* VS build/run cycle works, with slightly awkward requirement to always build all

* Update manifest

* Plugin template fixes

* Minor adjustments

* Build install as part of build command, instead of separately

* Test cleanup

* Update Linux test for adjusted generated CMake approach

* Plugin test typo fix

* Add missing stub file for project test

* Add a constant for VS generator

* Update project.pbxproj files to say Flutter rather than Chromium

Also, the templates now have an empty organization so that we don't cause people to give their apps a Flutter copyright.

* Update the copyright notice checker to require a standard notice on all files

* Update copyrights on Dart files. (This was a mechanical commit.)

* Fix weird license headers on Dart files that deviate from our conventions; relicense Shrine.

Some were already marked "The Flutter Authors", not clear why. Their
dates have been normalized. Some were missing the blank line after the
license. Some were randomly different in trivial ways for no apparent
reason (e.g. missing the trailing period).

* Clean up the copyrights in non-Dart files. (Manual edits.)

Also, make sure templates don't have copyrights.

* Fix some more ORGANIZATIONNAMEs

Fix some places where Debug/Release was treated as a binary switch.

Makes similar changes to Windows and Linux to simplify adding profile
support to those platforms in the future. This means `--profile` builds
will fail on Linux and Windows for now, but that's fine since they
aren't actually supported, and unlike `--release` don't provide useful
functionality at the native code level.

Also fixes 'stopApp' always using Debug on macOS, to avoid showing an
error when running Profile (or Release).

Fixes #33203

Allows Windows builds to use the same structure and script as Linux
builds now use, calling into tool_backend to manage copying resources to
the project directory and building the bundle.

Also switches from expecting name_update.bat to expecting flutter\exe_filename
to be written during the build, as with the recent changes to the macOS build, to
reduce the amount of boilerplate needed in a windows\ project directory.