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.
* Add new macos target configured for flavors
* Rename Free App copy-Info.plist to Free App Info.plist
* Remove bogus entitlements
* Remove Generated.xcconfig
* Audit project.pbxproj
* Remove unused configs
* share one info.plist
* Modify scheme so that paid app works
* Codesign automatic
* Pipe flavor as scheme into xcodebuild
* Ignore incoming flavor string
* pipe flavor for flutter run to work
* Add devicelab tests
* Error if host and target device are same for flutter install desktop
* Avoid bang (!) by promoting a local.
Co-authored-by: Jenn Magder <magder@google.com>
* Add supportsInstall property
* Override in test classes
* Add install test on macOS
* Refactor application_package and add tests for package directory
Co-authored-by: a-wallen <stephenwallen@google.com>
Co-authored-by: Jenn Magder <magder@google.com>
Depending on the user's build configuration, we may output
multi-architecture or single-architecture binaries. Prefer to install
the multi-architecture binary if built, otherwise fall back to the
single-architecture binary.
This eliminates the use of the Install.ps1 script during Windows app
installation and instead uses uwptool install. Install.ps1 was the
slowest part of app install, and had resource contention issues that
frequently caused it to fail.
Adds UwpTool.install and UwpTool.uninstall methods. Refactors the
PowerShell-based install code to move the powershell-related bits out of
the Device class and into UwpTool so that when we swap out the
PowerShell-based install for the uwptool-based install, it's transparent
to the WindowsUWPDevice class.
Adds implementations for:
* WindowsUWPDevice.isAppInstalled
* WindowsUWPDevice.uninstallApp
Refactors:
* WindowsUWPDevice.installApp
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
Refactors the desktop devices and workflow to remove unnecessary usage of global variables. This should make it easier to test and continue enhancing the desktop functionality of the tooling
#47161
* 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
In google3, the Linux device is always available, and it has confused
people who run the Flutter doctor and see
"• Linux • Linux • linux-x64 • Linux" listed.
Rename the Linux device name to "Linux desktop" and the device ID to
be "linux". Make similar changes to the Windows and macOS
devices for consistency. This is also consistent with the web
devices.
The device ID change shouldn't be break -d usage since that does a
case-insensitive prefix match.
instead of restricting profile/release mode based on whether the tool thinks the device is an emulator, restrict based on the device target architecture and the requested build mode. Notably, this enables release mode on x86_64 Android emulators, but not x86 emulators since we do not support that as an AOT target.
This does not add release mode support for simulators, since this requires us to build and upload artifacts for simulator/x86_64
Throw a toolExit if the windows plugin logic runs on an invalid windows project. Update the supported project check to validate the existence of a Runner.sln file
* 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
...because otherwise, processes that think they're manipulating your
filesystem will be doing crazy things the test is ignoring, leading to
(at best) failures and (at worst) flakes or disk corruption.
