Warn before Flutter upgrade on Windows

[LyViolz]

Addresses #7668.

On Windows, Flutter SDK files may be locked by IDE processes during an upgrade. This change warns users, recommends closing the IDE and running flutter upgrade in a terminal, and lets them continue from the IDE if they choose. The warning does not assume that every Windows upgrade fails.

Linux and macOS behavior is unchanged.

Testing

• gradlew.bat compileJava passed on Windows.
• gradlew.bat test --tests 'io.flutter.actions.*' passed: 12 tests, 0 failures, 0 skipped. This run included a temporary local action harness; the repository's existing action tests also passed.
• With a locally configured Flutter SDK, the Windows action prompt was exercised: Cancel is the default, and Continue reaches the upgrade action.
• I did not run flutter upgrade against the local SDK, since that would modify the SDK. The reported Dart SDK file-lock failure itself was not reproduced locally.

[gemini-code-assist]

Code Review

This pull request adds a warning dialog for Windows users when attempting to upgrade Flutter from within the IDE, as the Dart SDK may be locked by active IDE processes. The review feedback highlights two issues: first, the overridden actionPerformed method in FlutterUpgradeAction needs to report analytics before returning early on Windows to comply with the repository style guide; second, the double single quotes in the newly added properties message should be replaced with single quotes, as the message does not contain format parameters and would otherwise render literally.

[gemini-code-assist]

[CONCERN] In IntelliJ properties files, single quotes should only be doubled (''...) if the message contains format parameters (like {0}). Since this message does not contain any parameters, the double single quotes will be rendered literally as double single quotes in the UI. Use single quotes instead.

flutter.upgrade.windows.message=Flutter upgrades can fail on Windows while the IDE is running because the Dart SDK may be locked by IDE processes. Close the IDE and run 'flutter upgrade' from a terminal instead.

[helin24]

Does this upgrade command always fail on windows? (I am trying to understand if this change is likely to raise complaints from others who are using the upgrade successfully)

The associated issue also mentions that other SDK commands also fail. Are you able to reproduce that as well? If so, we may want this suggestion within the superclass instead of overriding just for upgrade.

[LyViolz]

Thanks for the clarification.

I haven't been able to reproduce the Windows-specific failure locally, since my development environment is Linux, so I can't confirm that flutter upgrade always fails on Windows or that the other SDK commands mentioned in the issue fail under the same conditions.

My change was based on the issue reports describing Dart SDK files being locked while the IDE is running. Given your concern, I agree that blocking flutter upgrade unconditionally on Windows may be too broad if the command works successfully for some users.

I can revise the approach once we determine whether this is specific to upgrade or applies to SDK commands more generally. If the same locking condition affects multiple commands, handling it in the superclass sounds more appropriate.

[LyViolz]

I revised the Windows behavior to address the concern about blocking upgrades for users who are not affected. The dialog now recommends closing the IDE and running flutter upgrade in a terminal, while offering a “Continue with upgrade” option; Cancel is the default. Linux and macOS are unchanged, and analytics are reported on both choices.

I have not rerun the Gradle compile or action tests after this update, and I could not verify the Windows behavior locally. The earlier PR test results predate this confirmation-dialog change.

[LyViolz]

Follow-up: I was able to run the checks on the updated head f75e8513 after moving the test workspace and Gradle cache to a drive with sufficient space.

• gradlew.bat compileJava passed.
• gradlew.bat test --tests 'io.flutter.actions.*' passed: 10 tests, 0 failures, 0 skipped.

The Windows-specific runtime behavior remains unverified locally.

[LyViolz]

Windows verification update:

• gradlew.bat compileJava passed.
• gradlew.bat test --tests 'io.flutter.actions.*' passed: 12 tests, 0 failures, 0 skipped (10 repository action tests plus 2 temporary local action-flow checks).
• The Windows flow showed the warning with Cancel selected by default; choosing Continue delegated to the upgrade action.

I did not run flutter upgrade against the configured local SDK, since that would modify it, so I have not reproduced the reported Dart SDK directory-lock failure locally. The dialog remains a Windows-only workaround that explains the known IDE/Dart process lock and gives users a choice; it does not claim every Windows upgrade fails.