Add menu for copying adb connect command that uses cvdr

[k311093]

Add sub-menu for device that copies adb connect command to the clipboard.

the command would be like

cvdr connect --connect_agent=websocket_agent --service_url=https://127.0.0.1:1443/ --host=websocket cvd-1

[ser-io]

this needs further discussion, the command cvdr connect --connect_agent=websocket_agent --service_url=https://127.0.0.1:1443/ --host=websocket cvd-1 is not going to work for instances created in GCP for example.

[k311093]

this needs further discussion, the command cvdr connect --connect_agent=websocket_agent --service_url=https://127.0.0.1:1443/ --host=websocket cvd-1 is not going to work for instances created in GCP for example.

I checked with GCP instance and found that handshake is succeeded but it looks like failing to sending data, it might be because it uses WebSocket.

It might be two options to solve this

1. Proxy WebSocket at CO
2. Under GCP environment, copies normal cvdr command like cvdr connect service_url=https://.../ --zone=us-central1-c --host=cf-00000-0000 cvd-1

Looks like Option 2 can be simpler.

What do you think?

[0405ysj]

Random idea: Mixed approach seems better for me, to make it clear for any types of our environment(Operator, HO, and CO).

• Define a new subpath that providing cvdr command text.
• WebUI reads response from that subpath, for providing command text via clicking button.
• Override that subpath by CO.

[ser-io]

this needs further discussion, the command cvdr connect --connect_agent=websocket_agent --service_url=https://127.0.0.1:1443/ --host=websocket cvd-1 is not going to work for instances created in GCP for example.

I checked with GCP instance and found that handshake is succeeded but it looks like failing to sending data, it might be because it uses WebSocket.

It might be two options to solve this

1. Proxy WebSocket at CO
2. Under GCP environment, copies normal cvdr command like cvdr connect service_url=https://.../ --zone=us-central1-c --host=cf-00000-0000 cvd-1

Looks like Option 2 can be simpler.

What do you think?

I think this should be a placeholder to be filled out only by the CO, there should not be a cvdr command in the UI if there's not a CO in the middle. If using cuttlefish on local workflows devices are already connected via adb and there's no need for cvdr.

Using cvdr with port forwarding connecting to either the HO or the Operator instead of the CO is confusing as it's not being used as intended from the original design, service_url is meant to be CO API only, not the Operator or the HO API. As some functionalities of the CO API is just a proxy we can afford to omit the CO when developing, but we should not promote these shortcut to final users.

By implementing Option.1 Proxy WebSocket at CO See b/352377928, we can continue to be aligned with cvdr original design of connecting only with the CO.

If we do need to connect directly to HO or Operator APIs running on a remote machine via port forwarding, let's have a meeting to discuss it.

[k311093]

this needs further discussion, the command cvdr connect --connect_agent=websocket_agent --service_url=https://127.0.0.1:1443/ --host=websocket cvd-1 is not going to work for instances created in GCP for example.

I checked with GCP instance and found that handshake is succeeded but it looks like failing to sending data, it might be because it uses WebSocket.
It might be two options to solve this

1. Proxy WebSocket at CO
2. Under GCP environment, copies normal cvdr command like cvdr connect service_url=https://.../ --zone=us-central1-c --host=cf-00000-0000 cvd-1

Looks like Option 2 can be simpler.
What do you think?

I think this should be a placeholder to be filled out only by the CO, there should not be a cvdr command in the UI if there's not a CO in the middle. If using cuttlefish on local workflows devices are already connected via adb and there's no need for cvdr.

Using cvdr with port forwarding connecting to either the HO or the Operator instead of the CO is confusing as it's not being used as intended from the original design, service_url is meant to be CO API only, not the Operator or the HO API. As some functionalities of the CO API is just a proxy we can afford to omit the CO when developing, but we should not promote these shortcut to final users.

By implementing Option.1 Proxy WebSocket at CO See b/352377928, we can continue to be aligned with cvdr original design of connecting only with the CO.

If we do need to connect directly to HO or Operator APIs running on a remote machine via port forwarding, let's have a meeting to discuss it.

Oh, I see the concepts between CO and cvdr.

Let me first try to proxy WebSocket at CO. And then fix cvdr to follow the concept cvdr connect --connect_agent=websocket_agent --service_url=https://address.to.co/ --host=cf-aaaaaa cvd-1 (I used service_url as endpoint URL for Operator, will change to CO's url).

And then I'll revisit this PR later.

Thanks!