android: don't set vpnService to nil when state is Stopped #523
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kari-ts
force-pushed
the
kari/nilservice
branch
from
d537a0d to
4d8af19
Compare
nickkhyl
approved these changes
Sep 30, 2024
kari-ts
force-pushed
the
kari/nilservice
branch
2 times, most recently
from
46e57af to
f497b01
Compare
|
Thanks for the review! I made another change to use stopSelf instead of stopForeground for when we disconnect the VPN; the latter only stops the service when more memory is needed, but when there is an error we want to kill the service completely |
We are currently setting vpnService.service to nil: -any time there’s an error with updateTUN -when we exit out of runBackend -if the config is the default config (aka when the ipn state is Stopped) When it gets set to nil, we don’t handle state or config updates by calling updateTUN until after startVPN is called again. The second case never happens because there’s no condition to break out of the loop in runBackend and ctx is uncancelable per the doc for context.Background() In the third case, we should not establish the VPN; the state is already in the correct Stopped state, but there’s no need to set the service to nil and prevent updateTUN from being called. The quick settings tile bug is caused by this third case, where because the saved prefs starts the app up in the Stopped state, the config is set to the default config, and the service is set to nil, and we can't updateTUN until there’s another startVPN call. This PR: -cleans up the updateTUN error handling to be more consistent -removes the IPNService parameter from updateTUN so that vpnService.service is not set to nil in the third case -updates IPNService to use stopSelf and not stopForeground when we disconnect the VPN; the latter only disconnects if there is a memory need Fixes tailscale/tailscale#12489 Signed-off-by: kari-ts <[email protected]>
kari-ts
force-pushed
the
kari/nilservice
branch
from
f497b01 to
a2a81c5
Compare
nickkhyl
approved these changes
Sep 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We are currently setting vpnService.service to nil: -any time there’s an error with updateTUN
-when we exit out of runBackend
-if the config is the default config (aka when the ipn state is Stopped)
When it gets set to nil, we don’t handle state or config updates by calling updateTUN until after startVPN is called again. The second case never happens because there’s no condition to break out of the loop in runBackend and ctx is uncancelable per the doc for context.Background() In the third case, we should not establish the VPN; the state is already in the correct Stopped state, but there’s no need to set the service to nil and prevent updateTUN from being called. The quick settings tile bug is caused by this third case, where because the saved prefs starts the app up in the Stopped state, the config is set to the default config, and the service is set to nil, and we can't updateTUN until there’s another startVPN call.
This PR:
-cleans up the updateTUN error handling to be more consistent -removes the IPNService parameter from updateTUN so that vpnService.service is not set to nil in the third case
Fixes tailscale/tailscale#12489