[flutter_tools] Add DeviceService app launch and flutter run support for tool extensions - #194589

Should we make the extension responsible for building the app as part of launchApp? This would help reduce communication between the tool and the extension. It also gives the extension greater control over what happens before/after the app is built.

Keeping the build step orchestrated by the host in ExtensionBackedDevice.startApp lets startApp support prebuiltApplication: true (--use-application-binary) without rebuilding, and lets the host resolve build output directories, artifact dependencies, and flutter assemble targets before passing the resulting binary URI to DeviceService.launchApp.

I still feel uncertain but I'd be fine with this approach if we feel confident this will support all Android/iOS/web scenarios.

Today a device can have different build logic for its flutter build foo and flutter run -d foo commands. There might not be a flutter build subcommand that mirrors the build logic that runs on flutter run -d foo. But if this is a real scenario, I suspect we might be able to address it by supporting "hidden" build targets.

If a device needs separate build logic for flutter run that shouldn't be exposed as a flutter build subcommand, we could also allow TargetDevice to reference an AssembleTarget (which is already internal to flutter assemble) rather than needing hidden BuildTargets.

With this current pattern, if we need to add an optional argument to getVmServiceUri, changing the method signature would be a breaking change. Instead, we'd need to introduce a new method with the new optional argument.

Perhaps all ToolExtensionService methods that an extension implements should accept an FooOptions object. For example, this would be:

final class GetVmServiceUriOptions { 
  GetVmServiceUriOptions({
    required this.deviceId,
  });

  final String deviceId;
}

abstract base class DeviceService extends ToolExtensionService {
  Future<Uri?> getVmServiceUri(GetVmServiceUriOptions options);
}

(Apologies if I've already commented on this and I'm repeating feedback!)

Since extensions can constrain their package:flutter_tools_extension dependency in pubspec.yaml, signature changes only affect extensions when they explicitly bump their dependency constraint. The cross-version compatibility boundary between a newer flutter_tools SDK and an already-published extension is the JSON-RPC wire protocol, so keeping the wire protocol tolerant to new request fields and response object properties can give us compatibility without needing FooOptions wrappers on every method.

I think that encouraging extension authors to pin their package:flutter_tools_extension dependency or use caret version ranges would accomplish the same thing as wrapper objects if we respect semver properly. I'm not a huge fan of wrapper objects for parameters, but I do agree that they're probably the most robust way to handle adding additional parameters. I'm open to having a discussion on this :)

Since extensions can constrain their package:flutter_tools_extension dependency in pubspec.yaml, signature changes only affect extensions when they explicitly bump their dependency constraint.

Ah and if I remember correctly, two extension can have two different package:flutter_tools_extension versions? If that's the case, I'm OK with skipping wrapper objects.

Yes, that's correct! Individual extensions can have completely different dependencies, including conflicting ones.

Hey, it looks like ExtensionBuildTarget.name doesn't validate the extension's value. We should also add some docs to explain what's legal or not. Feel free to punt to another PR though.

Added ExtensionBuildTarget.isValidName validation and documented the valid target name format on ExtensionBuildTarget.name, BuildTarget.name, and TargetDevice.buildTarget.