Previously VPN permissions were requested when the UI was loaded. If the
user denied the permissions it would have to be force stopped and
reopened to get another permission request grant.
Additionally, when requesting VPN permissions Android will kill any
other running VPN service. This avoids that behavior unless a site is
explicitly started.
Also disables the app from showing up in the "Always On" settings.
I think this closes the loop on DNS issues I was experiencing.
Previously, after starting Nebula, DNS would work until you switched
networks (e.g. from mobile to WiFi or vice-versa). This was fixed by
removing some explicit DNS server sets in commit
a283bf8010. This casued DNS to work in
`adb shell` even after toggling networks.
However, it did not actually fix the problem for Android applications.
The new behavior is that they would work while on WiFi, but fail on a
mobile network.
To quote Android docs:
> Allows traffic from the specified address family. By default, if no
> address, route or DNS server of a specific family (IPv4 or IPv6) is
> added to this VPN, then all outgoing traffic of that family is blocked.
> If any address, route or DNS server is added, that family is allowed.
> This method allows an address family to be unblocked even without adding
> an address, route or DNS server of that family. Traffic of that family
> will then typically fall-through to the underlying network if it's
> supported. family must be either AF_INET (for IPv4) or AF_INET6 (for
> IPv6). IllegalArgumentException is thrown if it's neither.
In my case, my home network supports only IPv4 while my mobile network
uses DNS over IPv6. Since my Nebula routes are IPv4-only, IPv6 traffic
stopped working, and DNS requests failed.
Previously when `stopVpn()` was called, it was possible for the network
change callback to fire while we were in the middle of shutting down.
This commit unregisters the network change callback before telling
Nebula to shutdown.
John Maguire
Nate Brown
Caleb Jasik
Nate Brown
John Maguire