-
Notifications
You must be signed in to change notification settings - Fork 402
fix(android): Use DisconnectMonitor to shut tunnel down when VPN is disconnected #6495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| </queries> | ||
|
|
||
| <application | ||
| android:enableOnBackInvokedCallback="true" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This prevents a minor warning on Android 13
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could have theoretically been possible for serviceBound = true even when tunnelService fails to initialize, so that's fixed here.
thomaseizinger
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am kind of worried about all these things being not tested in an automated way but I guess such is the life of app development.
| val ipv4Found = linkProperties.linkAddresses.find { it.address.hostAddress == tunnelService.tunnelIpv4Address } | ||
| val ipv6Found = linkProperties.linkAddresses.find { it.address.hostAddress == tunnelService.tunnelIpv6Address } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to guard against tunnelIpv4Address being null here to avoid a potential null == null comparison? These are null before we start-up right? Might be more of a defense-in-depth thing because there is nothing to shut down if we aren't started up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I don't think that's a possibility, but I'll refactor this just in case.
When a user disconnects our VPN from system settings, Android does not call any of the typical TunnelService callbacks. It does, however, send a standard NetworkMonitor event we can intercept in the
onLostcallback. We use that to shut down the TunnelService if we detect our VPN network has been lost.Unfortunately, network monitoring in Android is broad - we are notified when any network is lost, not just ours. So to filter others out, we listen for
linkPropertieschanging, and if the link addresses match our tunnel IPv4 and IPv6, we save that network ID to match on in theonLostcallback later.Resolves #5413