Support iOS wireless debugging

[vashworth]

Allows you to run flutter with a wireless iOS device. Uses mDNS service to get the IP of the wireless device and then access the observatory using it.

Unlike when running through a usb device, the Dart VM port does not get forwarded. --device-vmservice-port and --dds-port works same as before. --host-vmservice-port is slightly different. Before it would use host-vmservice-port as the port to forward the Dart VM to if dds-port was also provided, but if dds-port was not provided, it would use host-vmservice-port as the port for the DDS service and select a random port for the forwarded Dart VM. With this change host-vmservice-port is not used for port forwarding since there is none. It will only be used as the port for the DDS service if dds-port is not provided, but if dds-port is provided host-vmservice-port is basically ignored.

I tested flutter run, flutter attach, flutter install, and flutter screenshot, flutter drive.

Fixes #15072.

Steps to setup

1. Attach a iOS device to your Mac.
2. Make sure device is on same wifi as Mac.
3. Make sure the device has a passcode set.
4. Open Xcode > Window > Devices and Simulators > Choose your phone, then check Connect via Network
   
   (If you don't get that little network icon next to the device name it probably didn't work, regardless of checkbox state.)
5. Unplug your device from USB.

Steps to test flutter run

1. Complete setup
2. flutter run --device-timeout 5

Steps to test flutter attach (with app running in Xcode)

1. Complete setup
2. Open Xcode > Product > Scheme > Edit Scheme
3. Click the Arguments tab at the top and then add --observatory-host=0.0.0.0 (IPv4) or --observatory-host=::0 (IPv6) as launch argument
   
4. Run through Xcode
5. flutter attach --device-timeout 5

Steps to test with IPv6

To test any of the above commands with IPv6, you need to use the --ipv6 flag when running the commands. You'll need to setup an IPv6 network. I used this tutorial to temporarily create an IPv6 network:
https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW16

Limitations

• Must run once connected and click "Allow" to network permission prompt. Fixed by 7b6da55.
• Manually need to setup iPhone with Xcode to be connected via network.
• Must be on same wifi (from what I can tell this is needed if running through Xcode too, so probably an acceptable limitation)
• It takes longer to find network devices and get their info. Currently if it takes longer than 2 seconds to find it, it will skip it and not show as a selectable option. To workaround this, you can use --device-timeout flag to set the timeout longer.
• For flutter attach to work (when running app in Xcode), user must manually add launch argument to Xcode.
• Cannot use --no-publish-port flag. mDNS is required for this to work.

Things still need to be done

This will still work even without these fixes, but these fixes will help stabilize it.

• iOS network device not available when doing flutter run #118109
  • Workaround: add flag --device-timeout 5
• Xcode build sometimes runs 'Thin Binary' script before 'Process Info.plist' which causes mDNS errors. #118058
  • Workaround: If repeatedly getting mDNS error, try flutter clean.
• iOS network device not selected when running/debugging in VSCode #118113
  • Workaround: VSCode > Run > Add/Open Configuration, add --device-timeout 5 as arg to default configuration (see below)

  • {
      ...
      "configurations": [
          {
              "name": "my_app",
              "request": "launch",
              "type": "dart",
              "args": ["--device-timeout", "5"]
          },
          ...
      ]
    }
    

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[vashworth]

I found that this took longer when using a network device. 60 seconds might be a bit generous, though. Sometimes 30 seconds is enough, but sometimes it's more like 35. Not sure if people's internet connections might influence this (mine is pretty fast), which is why I overestimated.

[jmagman]

Wow that's a long time. Maybe 45 and we'll see if we get complaints?

[vashworth]

Sounds good. Updated.

[vashworth]

@jmagman As we discussed before, this solution does not require any engine changes. However, the biggest drawback to this approach in my opinion is that you need to run in once while connected and click "Allow" for the network permission prompt. We could extend the timeout and print something in the command line to let them know they need to accept it, but I'm unsure of how to confirm that they did without some output from the engine to tell the tool. Let me know if you have any ideas.

[vashworth]

This change just gives some visual feedback that it's loading the devices.

[jmagman]

However, the biggest drawback to this approach in my opinion is that you need to run in once while connected and click "Allow" for the network permission prompt. We could extend the timeout and print something in the command line to let them know they need to accept it, but I'm unsure of how to confirm that they did without some output from the engine to tell the tool. Let me know if you have any ideas.

Which timeout is this hitting? Can we get rid of the timeout if we know we're on wireless? Generally in the tool we like to avoid hard timeouts and instead prefer "this is taking longer than expected..." type output.

[jmagman]

Messages like this need to be actionable by the user. What are they supposed to do in this case to fix it? When we have actionable errors like this we should throwToolExit.

Something like:

Suggested change

	_logger.printError('Port publication (publish-port) must be enabled for wireless debugging.');
	return LaunchResult.failed();
	throwToolExit('Cannot start app on wirelessly tethered iOS device. Try running again with the --publish-port flag');

Introduced in #67452 to prevent the pop-up from blocking the app in a CI setting.

Maybe drive should default to always publishing, and we update our CI scripts to pass --no-publish-port so users manually running tests won't hit this? wdyt?

[vashworth]

Updated the error message.

And thanks for the reminder about drive, I misunderstood the first time we talked about it. I tried a different approach, so basically added an override for disablePortPublication that checks if the flag wasn't provided as an actual argument and it's a network device, then changes publish-port to be enabled. It's a little bit hacky, but allows drive to continue functioning as it was before for all wired devices without needing to update anything. Let me know if you think that's not a good solution.

[jmagman]

Wow that's a long time. Maybe 45 and we'll see if we get complaints?

[vashworth]

Which timeout is this hitting? Can we get rid of the timeout if we know we're on wireless? Generally in the tool we like to avoid hard timeouts and instead prefer "this is taking longer than expected..." type output.

This lookup has a default timeout of 5 seconds

flutter/packages/flutter_tools/lib/src/mdns_discovery.dart

Lines 69 to 73 in b63c79c

	final List<PtrResourceRecord> pointerRecords = await _client
	.lookup<PtrResourceRecord>(
	ResourceRecordQuery.serverPointer(dartObservatoryName),
	)
	.toList();

In the comments of the lookup function, it describe the timeout as "The [timeout] parameter specifies how long the internal cache should hold on to the record.". However, from what I can tell in the code and having observed by testing it out, seems to me that timeout is how long it continues to look for records.
https://github.com/flutter/packages/blob/e1ab965985d4e8ab5fdcf1b9989cf1c22d770205/packages/multicast_dns/lib/multicast_dns.dart#L189-L228
https://github.com/flutter/packages/blob/e1ab965985d4e8ab5fdcf1b9989cf1c22d770205/packages/multicast_dns/lib/src/lookup_resolver.dart#L42-L45

So to remove the timeout, we'd have to update the multicast_dns package, which we could do. We could also just make it a really long timeout perhaps? And have a secondary timeout that warns them it's taking longer than expected? Just remembered it doesn't stop when it finds it.

[jmagman]

This lookup has a default timeout of 5 seconds

Can we keep retrying the lookup on the tool side when it times out?

[vashworth]

This lookup has a default timeout of 5 seconds

Can we keep retrying the lookup on the tool side when it times out?

That's a good idea, I'll try that

[jmagman]

This is looking great!

[jmagman]

This caller shouldn't have to know the guts of MDnsObservatoryDiscovery to know it's a 2 second timeout. Instead, try adding the lookup duration parameter into MDnsObservatoryDiscovery, and then add 200 ms to it out here.

[jmagman]

It looks like this restarts the lookup every 2 seconds. Can we instead let it look for longer, since the caller will handle "this is taking longer than expected"?

https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#never-check-if-a-port-is-available-before-using-it-never-add-timeouts-and-other-race-conditions

(I realize this contradicts the advice of #118104 (comment) but it seems like we can let the internal lookup take much longer until it finds the record, and the external caller to handle the "well this is taking awhile, make sure you hit Allow")

[vashworth]

How long did you have in mind? The default was 5 seconds, but when I tested it, 2 seconds was always enough time but maybe that's an invalid assumption. And this lookup does not end when it finds it, it will end at the timeout. So if you put a timeout of 30 seconds, it will run for 30 seconds regardless of what it finds. So if we put a higher timeout, that's longer that the user has to wait for it to finish even though it probably already found what it's looking for.

[jmagman]

And this lookup does not end when it finds it, it will end at the timeout.

It looks like it's returning a Stream, are you sure it's not waiting that long because you added a toList() at the end, which will wait until the stream is closed?
https://github.com/flutter/packages/blob/e1ab965985d4e8ab5fdcf1b9989cf1c22d770205/packages/multicast_dns/lib/src/lookup_resolver.dart#L48

See their await for example:
https://github.com/flutter/packages/blob/88585ef98897007eacc1895f90e1288b5624b960/packages/multicast_dns/example/main.dart#L21-L22

[vashworth]

You're right, I see. I refactored so it stays open for longer (10 minutes). Let me know if you think longer/shorter time would be better

[jmagman]

Why don't we want to cache the results? Will the presence of anything in the cache cause it to not to try and lookup anything again?

[vashworth]

Exactly, so if it finds records in the first 5 second poll but it doesn't match the parameters (app id and/or device port), those results are cached and then the next poll will end immediately because it gets from the cache.

https://github.com/flutter/packages/blob/62e04e1267c7f10cc00e6a4334213656b46d3964/packages/multicast_dns/lib/multicast_dns.dart#L208-L216

[lattice0]

Is this usable? I couldn't get my Android Emulator on another computer to connect over a specific port using this option host-vmservice-port

[vashworth]

Is this usable? I couldn't get my Android Emulator on another computer to connect over a specific port using this option host-vmservice-port

iOS wireless debugging is enabled, but sounds like what you're trying to do is something else. Please file a new issue.