Implement ability for Flutter tooling to discover isolates in an Android app. Needed by attach command.

[matthew-carroll]

Implement ability for Flutter tooling to discover engine ports for running engines in an Android app. Needed by attach command.

This ability used to exist via BroadcastReceivers but the tooling was out of date and the Android code was removed.

This ability should be reintroduced and the tooling updated.

[mklim]

I think this may already be fixed, or maybe I'm misunderstanding the issue. flutter attach is already able to automatically discover and work with examples/flutter_view for me.

It looks like flutter attach finds a port to attach to by parsing the device logs if the port isn't specified at the command line. The add to app flow still logs everything normally, so there isn't an inherent incompatibility there.

[mklim]

What do you think @matthew-carroll?

[matthew-carroll]

@mklim what we're looking for here is the ability for the tooling to speak directly to the Android app to discover all running engines at a given moment.

It's true that we currently support log parsing but that comes with a problem. As engines come and go, the logs end up with ports that are no longer available. It's also very tedious for developers to watch logs for this info.

What we'd like to facilitate is the ability for both the IDE and the CLI to essentially say "Hey Android app, list every Flutter engine that's running right now and give me its port." Then the developer can select which ever engine he/she wants to attach to.

When the CLI is invoked, we can expect that either there is only 1 device available, or the developer has provided the device to target. From there we should be able to use ADB to send an Intent from the OS that will be received by some part of our app (the part that we need to write). After that it's worth considering the appropriate way for the responding Activity or BroadcastReceiver to determine which engines are currently running.

[mklim]

Got it, thanks for the clarification. So the problem isn't that flutter attach doesn't work with Add2App in general. It's that with Add2App there could be multiple instances of the engine running at once, and flutter attach always just picks one now using log parsing. This issue is to add the option for devs to see all the running instances listed, and then pick one.

[matthew-carroll]

Yeah, pretty much. Initially the goal is to create the capability to discover the active ports. We can then discuss the best way to represent that at the CLI. Then the IDE needs to leverage the CLI.

[mklim]

This is blocked on #22750.

[mklim]

Updating the title and defining this a little differently based on the above issue.

Port discovery isn't the problem here, since there's generally only going to be one port per Dart VM and process. But we should be able to find and specify which isolate within that port we're attaching to.

[mklim]

Looks like the flutter tooling is already aware of all the different isolates. See FlutterView in vmservice.dart. That already has a handle to a particular uiIsolate. Each connected device has an array of views.

The bad news is that I'm seeing one command broadcast to all available isolates because it looks like generally the flutter commands deliberately loop through all devices, and then all FlutterViews, for every command. See this segment in run_hot.dart for a single example of this, but there's instances of that nested loop everywhere in the file.

I think the change we want there is to probably refactor the tooling to take a flag for specific isolates to talk to, and then factor out all these for loops to act on a list that's filtered down to the selected isolate, if present.

It's also worth noting that in the Observatory it is possible to connect to and debug a specific isolate. But from what I can tell the VSCode debugger runs on all isolates simultaneously. There may be more cases with our tooling like this that handle multiple isolates in different ways that I'm not aware of at the moment.

/cc @DanTup