[tool] Migrate flutter_tools commands to modular dependency injection - #188471

Refactor `CleanCommand` to receive its dependencies via explicit modular contexts.

- Updated `CleanCommand` constructor to require `ToolContext` and `AppleContext`.
- Refactored all internal logic in `CleanCommand` to resolve dependencies via injected contexts instead of `globals`.
- Updated `FlutterCommand` base class to accept optional `ToolContext` and expose fallback getters to maintain 100% backward compatibility.
- Resolved a covariance violation in `custom_devices.dart` by making `CustomDevicesCommandBase.fileSystem` non-nullable.
- Wired contexts into `CleanCommand` registration inside `executable.dart`.
- Refactored `clean_test.dart` to use localized mock/fake contexts, verifying hermetic execution.

This establishes a clean, verified template for migrating the remaining commands in Phase 3.

Refactor `ChannelCommand` to receive its dependencies via explicit modular contexts.

- Updated `ChannelCommand` constructor to require `ToolContext`.
- Refactored all internal logic in `ChannelCommand` to resolve dependencies via injected contexts instead of `globals`.
- Refactored `ChannelCommand.upgradeChannel` and `_checkout` static methods to explicitly accept their dependencies as arguments, preventing global state leakage.
- Added `FlutterVersion flutterVersion` to `ToolContext` and wired it into `ToolDependencies.bootstrap`.
- Updated `UpgradeCommand` callsites to pass explicit dependencies to `ChannelCommand.upgradeChannel`.
- Resolved covariance and `annotate_overrides` warnings in `build.dart`, `build_ios_framework.dart`, and `widget_preview.dart` due to new getters on the base class.
- Refactored `channel_test.dart` to use `FakeToolContext` and added a new test explicitly verifying that the command resolves its dependencies from the injected context rather than the Zone.

This continues our incremental command migration in Phase 3.

Refactor `ConfigCommand` to receive its dependencies via explicit modular contexts.

- Updated `ConfigCommand` constructor to require `ToolContext` and `AndroidContext`.
- Refactored all internal logic in `ConfigCommand` to resolve dependencies via injected contexts instead of `globals`.
- Added `config` and `terminal` (typed as `Terminal` to prevent covariant conflicts) getters to the `FlutterCommand` base class with safe global fallbacks.
- Wired contexts into `ConfigCommand` registration inside `executable.dart`.
- Refactored `config_test.dart` to use `FakeToolContext` and `FakeAndroidContext` and added two new DI validation tests explicitly verifying that the command resolves its dependencies from the injected contexts rather than the Zone.

This continues our incremental command migration in Phase 3.

Refactor `ScreenshotCommand` to receive its dependencies via explicit modular contexts.

- Updated `ScreenshotCommand` constructor to require `ToolContext`.
- Refactored all internal logic in `ScreenshotCommand` to resolve dependencies via injected contexts instead of `globals`.
- Added `fileSystemUtils` getter to the `FlutterCommand` base class with safe global fallbacks.
- Resolved a Dart flow-analysis type promotion warning by introducing a non-nullable local copy of `outputFile` to ensure clean promotion in closures.
- Wired contexts into `ScreenshotCommand` registration inside `executable.dart`.
- Refactored `screenshot_command_test.dart` to use `FakeToolContext` and added a new DI validation test group.

This continues our incremental command migration in Phase 3.

Refactor `SymbolizeCommand` to receive its dependencies via explicit modular contexts.

- Updated `SymbolizeCommand` constructor to require `ToolContext`.
- Refactored all internal logic in `SymbolizeCommand` to resolve dependencies via injected contexts instead of `globals`.
- Added `stdio` getter to the `FlutterCommand` base class with safe global fallbacks.
- Wired contexts into `SymbolizeCommand` registration inside `executable.dart`.
- Refactored `symbolize_test.dart` to use `FakeToolContext` and added a new DI validation test.

This continues our incremental command migration in Phase 3.

Refactor `DoctorCommand` and expand the DI container to support the `Doctor` service.

- Added `Doctor doctor` to the modular `ToolContext` container.
- Topologically bootstrapped `Doctor` inside `ToolDependencies.bootstrap` using the already-constructed logger and clock.
- Exposed a `doctor` getter on the `FlutterCommand` base class with safe global fallbacks to preserve backward compatibility.
- Refactored `DoctorCommand` constructor to require `ToolContext` and updated all internal code to use the inherited `doctor` getter instead of `globals.doctor`.
- Wired contexts into `DoctorCommand` registration inside `executable.dart`.
- Refactored `doctor_test.dart` to use `FakeToolContext` and added 3 new DI validation tests.
- Updated `dependency_injection_test.dart` to assert `doctor` bootstrapping.

This expands our explicit DI container and continues Phase 3 command migration.

Expand explicit dependency injection container to topologically bootstrap the entire device discovery infrastructure.

- Added `OperatingSystemUtils os`, `Artifacts artifacts`, `WindowsWorkflow windowsWorkflow`, `MacOSWorkflow macOSWorkflow`, and `DeviceManager deviceManager` to the core `ToolContext`.
- Added `AndroidWorkflow androidWorkflow` to `AndroidContext`.
- Added `IOSWorkflow iosWorkflow` and `IOSSimulatorUtils iosSimulatorUtils` to `AppleContext`.
- Topologically bootstrapped and wired all of these in `ToolDependencies.bootstrap(...)`.
- Updated `FlutterDeviceManager` constructor to accept nullable platform-specific dependencies, allowing robust platform-agnostic instantiation and registration.
- Exposed `os`, `artifacts`, and `deviceManager` getters on `FlutterCommand` base class with safe global fallbacks.
- Updated `dependency_injection_test.dart` to assert correct bootstrapping across different platforms and verify override propagation.

This is a major architectural milestone that enables explicit injection of the entire device discovery infrastructure at startup.

Refactor `DevicesCommand` to receive its dependencies via explicit modular contexts.

- Updated `DevicesCommand` constructor to require `ToolContext` as a named parameter.
- Refactored all internal logic in `DevicesCommand` to resolve `doctor`, `deviceManager`, `platform`, and `logger` from the inherited getters instead of `globals.xxx`.
- Completely removed `globals.dart` import from `devices.dart`.
- Wired contexts into `DevicesCommand` registration inside `executable.dart`.
- Refactored `runner_test.dart` to inject `toolContext` into its `DevicesCommand` instantiation, preventing compilation errors in other shards.
- Refactored `permeable/devices_test.dart` and `hermetic/devices_test.dart` to use `FakeToolContext` and `createDevicesCommand` helper (updating all 27 instantiations!).
- Added a highly robust, combined structural and behavioral DI validation test case in `hermetic/devices_test.dart` to verify explicit injection.

This continues our Phase 3 command migration, leveraging our explicitly bootstrapped `DeviceManager`.

Refactor `EmulatorsCommand` and expand the DI container to support the `EmulatorManager` service.

- Added `EmulatorManager emulatorManager` to the modular `ToolContext` container.
- Topologically bootstrapped `EmulatorManager` inside `ToolDependencies.bootstrap` using Android and core dependencies (`java`, `androidSdk`, `processManager`, `logger`, `fs`, `androidWorkflow`).
- Supported optional `EmulatorManager? emulatorManager` override in the bootstrapper for hermetic testing.
- Exposed `emulatorManager` getter on the `FlutterCommand` base class with safe Zone-based fallbacks.
- Refactored `EmulatorsCommand` constructor to require `ToolContext`, and refactored all internal code to use inherited getters instead of `globals.xxx`.
- Explicitly prefixed all `emulatorManager` references in `EmulatorsCommand` with `this.emulatorManager` to bypass Dart's lexical scope shadowing from `emulator.dart`.
- Wired contexts into `EmulatorsCommand` registration inside `executable.dart`.
- Wrote a brand-new, comprehensive hermetic unit test suite (`emulators_test.dart`) from scratch with 15 tests covering listing, launching, and creation behaviors.
- Updated `dependency_injection_test.dart` to assert correct bootstrapping and override propagation.

This expands our explicit DI container and continues Phase 3 command migration.

…vice

Refactor `DowngradeCommand` and expand the DI container to support the `PersistentToolState` service.

- Added `PersistentToolState persistentToolState` to the modular `ToolContext` container.
- Topologically bootstrapped `PersistentToolState` inside `ToolDependencies.bootstrap` using the container's file system and logger.
- Supported optional `PersistentToolState? persistentToolState` override in the bootstrapper for hermetic testing.
- Exposed `persistentToolState` getter on the `FlutterCommand` base class with safe global fallbacks.
- Refactored `DowngradeCommand` constructor to require `ToolContext`, and completely removed all other optional parameters (`persistentToolState`, `logger`, `flutterVersion`, `terminal`, `stdio`, `fileSystem`).
- Completely removed all private nullable fields and lazy-initialization blocks in `runCommand`, replacing them with direct, non-nullable inherited base class getters.
- Wired contexts into `DowngradeCommand` registration inside `executable.dart` (removing legacy overrides).
- Refactored `downgrade_test.dart` to use `FakeToolContext` and `setUpCommand` helper, and added a mathematically rigorous DI validation test.
- Solved the environment-specific Android SDK lookup failure in `downgrade_test.dart` by explicitly setting `command.applicationPackages = FakeApplicationPackageFactory();` in the setup.
- Updated `dependency_injection_test.dart` to assert correct bootstrapping and override propagation for `PersistentToolState` (implementing `isRunningOnBot` on `FakePersistentToolState` to prevent bootstrapping crash).

This expands our explicit DI container and continues Phase 3 command migration.

Refactor `InstallCommand` to receive its dependencies via explicit modular contexts.

- Updated `InstallCommand` constructor to require `ToolContext` as a named parameter.
- Refactored all internal logic in `InstallCommand` to resolve `fileSystem` and `logger` from inherited getters instead of `globals.xxx`.
- Decoupled the top-level helper function `installApp` by passing `Logger logger` explicitly and eliminating its internal `globals.xxx` logging dependencies.
- Completely removed `globals.dart` import from `install.dart`.
- Wired contexts into `InstallCommand` registration inside `executable.dart`.
- Refactored `install_test.dart` to use `FakeToolContext` and `createInstallCommand` helper (updating all 6 instantiations!).
- Added a dedicated DI validation test case in `install_test.dart` to verify explicit injection.

This continues our Phase 3 command migration.

Refactor `LogsCommand` to receive its dependencies via explicit modular contexts.

- Updated `LogsCommand` constructor to require `ToolContext` as a named parameter.
- Refactored all internal logic in `LogsCommand` to resolve `logger` from inherited getter instead of `globals.printStatus`.
- Completely removed `globals.dart` import from `logs.dart`.
- Wired contexts into `LogsCommand` registration inside `executable.dart`.
- Refactored `logs_test.dart` to use `FakeToolContext` and `createLogsCommand` helper (updating both instantiations!).
- Added a dedicated DI validation test case in `logs_test.dart` to verify explicit injection.

This continues our Phase 3 command migration.

Refactor `DebugAdapterCommand` to receive its dependencies via explicit modular contexts and resolve a pre-existing test regression.

- Updated `DebugAdapterCommand` constructor to require `ToolContext` as a named parameter.
- Refactored all internal logic in `DebugAdapterCommand` to resolve `stdio`, `fileSystem`, `platform`, and `logger` from inherited getters instead of `globals.xxx`.
- Completely removed `globals.dart` import from `debug_adapter.dart`.
- Wired contexts into `DebugAdapterCommand` registration inside `executable.dart`.
- Patched `FakeToolContext` in `args_test.dart` to delegate `flutterVersion` to `globals.flutterVersion` (mocked by `TestBed`), resolving a pre-existing crash where `ConfigCommand` reads `flutterVersion.channel` in its constructor during command generation checks.
- Wrote a brand-new, comprehensive hermetic unit test suite (`debug_adapter_test.dart`) from scratch with 2 tests covering startup/shutdown (clean exit on closed stdin) and deep DI validation.

This continues our Phase 3 command migration and improves general test health.

Refactor `UpgradeCommand` and `UpgradeCommandRunner` to receive their dependencies via explicit modular contexts, and decouple associated top-level helpers.

- Updated `UpgradeCommand` constructor to require `ToolContext` as a named parameter.
- Refactored `UpgradeCommandRunner` constructor to require `ToolContext` and resolve all dependencies (platform, git, flutterVersion, fs, logger, persistentToolState, processUtils) from the injected context instead of `globals.xxx`.
- Removed the mutable `SystemClock clock` field from `UpgradeCommandRunner`, resolving it instead via the injected context's `systemClock` to improve test isolation.
- Decoupled the top-level `precacheArtifacts` helper function by passing `ToolContext` explicitly and eliminating all its internal `globals.xxx` dependencies.
- Updated `ChannelCommand` to store the context and propagate it to the updated `precacheArtifacts` call.
- Completely removed `globals.dart` import from `upgrade.dart`.
- Wired contexts into `UpgradeCommand` registration inside `executable.dart`.
- Refactored `hermetic/upgrade_test.dart` to use a strict `FakeToolContext` and added a dedicated DI validation test case.
- Refactored `permeable/upgrade_test.dart` by implementing a `ZoneDelegatingToolContext` universal adapter, ensuring all 24 legacy Zone-based tests continue to pass perfectly with zero regressions.

This continues our Phase 3 command migration and achieves clean DI for one of our most complex SDK commands.

Refactor `ShellCompletionCommand` to receive its dependencies via explicit modular contexts, and purge globals from its unit tests.

- Updated `ShellCompletionCommand` constructor to require `ToolContext` as a named parameter.
- Refactored all internal logic in `ShellCompletionCommand` to resolve `stdio` and `fileSystem` from inherited getters instead of `globals.xxx`.
- Completely removed `globals.dart` import from `shell_completion.dart`.
- Wired contexts into `ShellCompletionCommand` registration inside `executable.dart`.
- Refactored `shell_completion_test.dart` to use `FakeToolContext` and a local `fileSystem` variable, completely purging `globals` from the test file.
- Replaced all 5 instantiations of `ShellCompletionCommand` in tests with the helper.
- Added a dedicated DI validation test case in `shell_completion_test.dart` using strict throwing mocks to prove perfect DI isolation.

This continues our Phase 3 command migration and achieves clean DI for our shell integration tools.

…roidSdk

By default, AndroidSdk.locateAndroidSdk constructed a new OperatingSystemUtils instance internally when resolving the SDK. This bypassed the FakeOperatingSystemUtils override provided by testUsingContext in hermetic tests, causing actual process execution (which -a aapt) that failed under FakeProcessManager when no matching commands were expected.

This change:
1. Adds an optional operatingSystemUtils parameter to AndroidSdk.locateAndroidSdk.
2. Uses the passed operatingSystemUtils or falls back to globals.os if no overrides are passed, ensuring that tests honoring the zone overrides will use the fake implementation.
3. Updates ToolDependencies.bootstrap to pass its constructed finalOS to locateAndroidSdk.
4. Fixes dependency_injection_test.dart by adding whichAll stub to FakeOperatingSystemUtils and passing mock Android SDK/Studio in overrides tests.