Implement USE_EXIT_NODE intent

[333fred]

Closes tailscale/tailscale#8143. I map friendly labels from intent extras to tailscale node IDs, with empty string or not specifying the exitNode intent extra as the "no exit node" action. When an error is encountered, we will push a notification with a friendly message to the status notification channel. The tasker syntax I tested with locally is:

Action: com.tailscale.ipn.USE_EXIT_NODE
Package: com.tailscale.ipn
Class: com.tailscale.ipn.IPNReceiver
Target: Broadcast Receiver
Extra: exitNode:exitNodeLabelOrEmpty
Extra: allowLanAccess:trueOrFalse

[333fred]

@DentonGentry hey, sorry for the ping, just trying to get someone to look at this pr.

[DentonGentry]

I understand and do intend to. We are finishing the 1.56 client release this week. We would want something like this to go in at the start of a new development cycle to potentially appear in 1.58, we need to finish 1.56 first.

[333fred]

I understand and do intend to. We are finishing the 1.56 client release this week. We would want something like this to go in at the start of a new development cycle to potentially appear in 1.58, we need to finish 1.56 first.

Perfectly fine. I just hadn't heard anything so I was making sure this was on the radar 🙂.

[333fred]

Hey @DentonGentry, no pressure intended, but do you have an idea when you'll be taking a look at this?

[Linutux]

I hope that the pull request will be merged soon. It's a feature I'm eagerly awaiting. I use MacroDroid for automations, depending on wifi connection etc. At home, "Use exit node" should be off, but on the road, please turn it on.

[333fred]

@DentonGentry @kari-ts, any status updates?

[333fred]

@DentonGentry @kari-ts, I'm trying to be patient here, but the radio silence is really starting to get frustrating. Can I please at least get an idea of when you'll look at this? I don't want to keep resolving merge conflicts if this is just never going to be looked at.

[nuentes]

I'm personally dying for this feature. Can it please get added asap?

[kari-ts]

@333fred thanks for the work here.

I'm making some changes that impact exit nodes now (#172, #176) - right now, whenever we want to make any changes to prefs, we call SetPrefs, which is intended for setting prefs for the first time, rather than editing the prefs. I also would like to prevent users from being able to use an exit node if they're currently running an exit node, and vice versa.

Once we switch to using EditPrefs instead of SetPrefs, if a user is using an exit node and tries to run an exit node or vice versa, we will fail this check. For this PR, this error should be handled and some UI telling the user why the action failed should be shown.

[333fred]

I see. These intents are normally run in the background, while tailscale isn't open, or indeed while the phone screen isn't even on; I'm not sure what UI would be best to try and show. Either toasts or notifications are likely options here. Perhaps a notification would be best, as toasts can easily be missed?

[kari-ts]

Adding @sonovawolf for UI input

[333fred]

@sonovawolf thoughts on the UI suggestions? I won't have time to work on the changes this weekend, but may be able to get to it some evening next week if I have a direction to go.

[sonovawolf]

Hey @333fred! We'd prefer to use notifications to communicate those errors.

[333fred]

@kari-ts I've had time to address the notification feedback; given the number of changes to the app since I initially submitted this PR, I simply rewrote the UseExitNodeWorker in Kotlin and force-pushed (I was also missing the Signed-off-by in my commits). This is ready for review.

[agottardo]

Thanks for updating your PR!

Can you please add new string resources to strings.xml, and reference these from your code wherever you're currently using hardcoded strings? It will make it easier for us to localize the app in the future.

[333fred]

@agottardo strings extracted.

[333fred]

Thanks for the reviews! Anything else you need from me before merging this?

[agottardo]

Thanks for the reviews! Anything else you need from me before merging this?

@333fred we'll take care of merging this as soon as QA has signed off on the 1.66 release, to land this PR in the next beta version (and ultimately the 1.68 release). 👍🏻

[agottardo]

@333fred sorry to bother you, but we had to refactor quite a few files to fix some last-minute bugs for the release. Can you please rebase this fixing the conflicts, and I'll get it merged? Thanks.