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
The tool observes a large number of unhandled exceptions during the file copy portion of flutter create. it is difficult to tell whether the permission issue is caused by the source/destination, or whether it is due to a bug in dart:io.
To work around this, implement a permission check for both the source and dest files. If either fails, the tool can exit with a more specific message.
If these checks pass, then perform the actual copy. If the copy fails, fallback to manually copying the bytes
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.
[flutter tools] Add a DelegatingLogger class
Move most of `DelegateLogger` `from test/src/testbed.dart` to
`lib/src/base/logger.dart` to better formalize the common practice of
chaining `Logger`s together. I renamed the class since it isn't
itself the delegate and to better match the `Delegating...` classes
from `package:collection`.
Additionally, add a freestanding `asLogger<T>` function to "cast" a
`Logger` into a matching delegate if possible. This will allow
`Logger` chains to be ordered a *bit* more freely (e.g.
`NotifyingLogger` and `AppRunLogger` will no longer required to be
at the end of the chain, an unwritten rule that has led to breakage in
google3). Chain order still matters since lack of virtual dispatch
means that parent `Logger`s can never invoke child methods, however.
I made `asLogger<T>` a freestanding function because I didn't want to
make it part of the `Logger` interface (and I thought that making it
an extension method might be weird).
Bonus cleanup:
There no longer appears to be a way to construct an `AppRunLogger`
with a null parent, so remove all of code paths for that case and
make the `parent` construction parameter required.
* [flutter_tools] handle case where file is deleted by other program
* Add test cases
* Update file_system.dart
* Update file_system_test.dart
* fix import
* make a static on ErrorHandligFS
* add support for no exit on failure
* address comments
* update doc comment to file or directory
This PR changes the Config class in flutter_tools to use the XDG Base directory specification instead of putting files directly in the user's home directory. If those files are already present in the home directory, they are used instead.
it is possible for users that download the prebuilt SDKs to run the tool without unzip installed. Rather than crashing with an unclear argument error, exit the tool with a message on how to install that mirrors the message in the update_dart_sdk.sh script.
Also applied to zip for completeness
Instead of always exiting the tool, provide a mechanism to turn off this behavior for non-critical functionality like configuration and analytics settings.
Fixes#66786Fixes#4674
This message is displayed if we do not find a pubspec.yaml
99% of the time this additional advice is going to have nothing to do with the actual error. Just remove it because it will cause more confusion than it could clear up
Crash reporting shows at least one instance of EACCES during an existsSync cache call. Add this to the list of error handling io methods. Did not add the async exists method since we lint against its usage.
Some terminals stdin do not support single char mode (like an emacs terminal buffer apparently). If this is the case, then the presented choice values would always have an appended newline \n which would prevent us from finding the value in the listed index (or using it as a signal for the default choice). To fix, treat '' as the default choice and always trim the choice value.
While this has seemingly always been broken, it wasn't noticeable until the multi-device selection prompt was added a few months ago.
Fixes#65267
The flutter tool is currently unable to detect missing permissions in gradle/gradle.bat that would cause a gradle build to fail via process exception. Rather than crashing and exiting, we can display the exception as an error message and tool exit.
While linux/macOS are able to add the +x bit, this is not possible on windows with our current file system/OS API. These crashes represent a substantial amount of crash reporting, but are otherwise not actionable on our end.
* Reland "Re-enable the Dart Development Service (DDS) (#64671)"
This reverts commit 2ae25cc2d7.
* Fix MDNS building Observatory URI with port 0 instead of forwarding the device port
* Added MDNS test
This change re-enables DDS and outputs the DDS URI in place of the VM
service URI on the console. If --disable-dds is not provided,
--host-vmservice-port will be used to determine the port for DDS rather
than the host port for the VM service, which will instead be randomly
chosen.
Adds support for size analysis on iOS, macOS, linux, and Windows - using an uncompressed directory based approach. The output format is not currently specified.
Adds support for size analysis on android on windows, switching to package:archive
Updates the console format to display as a tree, allowing longer paths. Increases the number of dart libraries shown (to avoid only ever printing the flutter/dart:ui libraries, which dominate the size)
This reverts commit adc9dde3ba.
- Fixed issue where `FallbackDiscovery` would hold on to a `VmService` when launching on iOS devices, causing DDS to fail to start
- Fixed `flutter drive` case where DDS is already running in another flutter_tools instance
We have too many loggers, and the logger construction rules are too complicated to be untested. Capture these in a LoggerFactory and test that construction is correct.
On Windows, Process.run assumes the output uses the system codepage by default. This allows specifying it in our wrapper, and sets the encoding for vswhere to UTF-8 since we're passing a flag that forces it to use UTF-8 output.
Fixes#53515
A frequent request from the last Flutter developer survey was for an easier method of testing light/dark mode changes. Currently, a user needs to manually change the theme settings or adjust phone settings to see the difference. Instead we should add a toggle from the CLI, and eventually devtools/Intellij/Vscode that allows developers to override the current setting.
Fixes#59495
Adds flutter.ext.brightnessOverride service protocol which either queries the current platform brightness, or overrides it to a new value. This accepts either Brightness.light or Brightness.dark as a value.
Adds a CLI toggle b which allows the setting to be toggled manually.
Requires an update to the MediaQuery, to conditionally use a debug override when not in release mode
Updates the tooling to use the GTK embedding, rather than the GLFW embedding:
- Adds new requirements to `doctor`
- Updates the app and plugin templates to make GTK-based runners and plugins
- Stops downloading and installing the GLFW artifacts
Final part of #54860, other than cleanup.
The tool was setting the output preferences in a sub-context. Originally these were not injected before the arg parsers were created, though that was fixed by the lazy command creation. Once local engine is removed, the inner flutter_command Zone can be removed.
Current versions of the Windows desktop build files don't require a specific Windows 10 SDK version, but doctor still checks for one since vswhere doesn't allow for flexible queries. This has been a common source of issues for people setting up on Windows for the first time, because the current VS installer by default only includes a newer version of the SDK than what doctor is looking for.
This removes the vswhere SDK check, and instead uses a manual check for SDKs. Since this uses undocumented (although fairly widely used, so relatively unlikely to change) registry information, the check is non-fatal, so that builds can progress even if the SDK isn't found by doctor; in practice, it's very unlikely that someone would install the C++ Windows development workload but remove the selected-by-default SDK from the install.
Now that all requirements are default, the instructions when missing VS have been simplified so that they no longer list individual components, and instead just say to include default items.
Fixes#50487
Work towards removal of package:archive and ideally more stable unzipping of artifacts. These commands are available in Powershell 5+, which we already require for windows.
Updates the Linux templates to use CMake+ninja, rather than Make, and updates the tooling to generate CMake support files rather than Make support files, and to drive the build using cmake and ninja.
Also updates doctor to check for cmake and ninja in place of make.
Note: While we could use CMake+Make rather than CMake+ninja, in testing ninja handled the tool_backend.sh call much better, calling it only once rather than once per dependent target. While it does add another dependency that people are less likely to already have, it's widely available in package managers, as well as being available as a direct download. Longer term, we could potentially switch from ninja to Make if it's an issue.
Fixes#52751
