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
Our current top crasher is an unclear error when ProcessManager fails to resolve an executable path. To fix this, we'd like to being adjusting the process resolution logic and adding more instrumentation to track failures. In order to begin the process, the ProcessManager has been folded back into the flutter tool
Instead of loading the use-material-design asset data from a yaml file in the repo, leave it in dart code and simplify. Remove some of the globals, but not enough to update to testWithoutContext
There have been some more additional reports of a missing 'package:characters' import after upgrading flutter. This has me concerned that our pub caching logic is incorrect. Instead of the tool attempting to guess when pub should be run, always delegate to pub.
Also takes an opportunity to fix the kernel snapshot depending on the .packages or package_config. Due to the generated: date field this causes extra rebuilds. Instead when pub get is run, write out an additional file with just the package contents and version.
Fixes#66777Fixes#65723
Reland of #67669
The flutter tool has a number of crashes on stable where an ArgumentError is thrown due to the process manager not being able to resolve an executable.
So that we can adjust/modify this logic, fold it into flutter and add some additional logging.
caches the resolved executable per target directory, to avoid repeated look ups.
Instead of throwing an argument error, attempts to run the executable as given if an exact path can't be found
Accept files or symlinks for the executable path.
user where/which to resolve path instead of package:process logic.
The flutter tool has a number of crashes on stable where an ArgumentError is thrown due to the process manager not being able to resolve an executable. Fold the resolution logic into the tool and use where/which instead of the package:process specific logic.