A VPN on Android: The Always-On Switch and the Private DNS Setting
Android is the mobile platform that hands you real controls rather than leaving them to whichever app you installed. The operating system itself can keep a tunnel always on, refuse to carry traffic when no tunnel is up, and include or exclude individual apps from it. It also has its own encrypted name-resolution setting that can quietly overlap with what the VPN wants to do. Those two facts — system-level controls, and a second opinion about DNS — are what makes this platform different, and both are worth setting deliberately.
The system owns the tunnel and lends you the switches
An app on Android requests permission to create a tunnel, and the operating system provides the plumbing. You approve it once, a persistent indicator appears, and from then on the tunnel is a system object. Only one can be active at a time.
The important consequence is that the controls worth using are not in the app. They are platform settings, they behave the same regardless of which app you chose, and they apply at points in time when no app interface has run yet — most importantly, immediately after the device boots. An app’s own equivalents are fine, but they are the app’s promises. The platform’s version is the platform’s behaviour.
Two settings that sound similar and are not
Keeping a tunnel always on is not the same as refusing to work without one. Android separates them, and the separation is the single most useful thing about VPN support on this platform.
The first setting says: bring this tunnel up and keep bringing it back. It is a reconnection policy. It reduces how long the device spends outside the tunnel, and it survives reboots, which the app cannot promise on its own.
The second setting says: if the tunnel is not up, do not carry traffic at all. That is the fail-closed behaviour people mean when they talk about a kill switch, implemented by the operating system rather than by an application, on a device that changes networks constantly. Turning the first on without the second gives you a tunnel that comes back quickly. Turning both on gives you a device that does not send anything in the meantime. Those are different guarantees and it is worth knowing which you have.
Per-app coverage is a platform facility, not a product feature
The operating system knows which app opened which connection, so it can route them differently. That is why per-app inclusion and exclusion works here at all, and why it cannot work at a router, which only ever sees packets.
The common honest reason to exclude an app is that it needs the local network: casting to a device in the room, reaching a drive at home, or talking to something on the same segment. Send that traffic into a tunnel and it goes to the far end and comes back looking like it came from the internet, which is not how local discovery works. Excluding it fixes the problem cleanly.
Be clear about the price. An excluded app uses the ordinary connection with the ordinary address, and the fail-closed setting above does not apply to it. Exclusions are the deliberate holes in your coverage, which is fine as long as you know which ones you cut. The general shape of that trade-off is what split tunnelling is about, and Android is the platform where it is a first-class facility rather than a client extra.
Private DNS and the tunnel’s resolver
Android has a system setting for sending name lookups encrypted to a resolver you name, and a VPN also wants to decide where lookups go. Two mechanisms with an opinion about the same thing, and which one prevails is implementation-dependent rather than something you can safely assume.
The two failure shapes are worth recognising. If the system’s encrypted-DNS setting takes precedence, your lookups are encrypted but going to a third party you chose, outside the tunnel — better than the local network reading them, and not what somebody who set up a VPN for privacy expected. If the tunnel’s resolver takes precedence, the resolver you carefully configured is being ignored, and the provider is seeing every name you look up.
Neither is a disaster and both are worth knowing about, which is why the relationship between encrypted DNS and a VPN is a more useful thing to understand on this platform than anywhere else. The practical advice is to check rather than assume, and to decide which party you would rather have the lookups: the resolver you named, or the tunnel you are already trusting with everything else.
What the switches do not cover
A few things sit outside even a well-configured setup. The platform’s own connectivity checks, some vendor services, and the brief window during boot before the tunnel is established. A device with no tunnel configured cannot be blocked into safety by a setting that has nothing to enforce. And any app you excluded is, by your own instruction, outside all of it.
There is also a category that catches people out: manufacturer power management. Vendor layers on top of Android are aggressive about stopping background work to save battery, and a VPN client is a background service. A tunnel that quietly dies overnight and is absent in the morning is very often this rather than a bug in the client. If the always-on setting is on and the tunnel still keeps going away, the power-management exclusions for that app are the place to look before blaming anything else.
Turning it off properly
Revoking the system permission is the real off switch. The always-on setting also has to be turned off before the app can be removed cleanly, and a device left in an odd state — a fail-closed setting pointing at an app that no longer exists — is the sort of thing that manifests later as a phone with no working internet and no obvious cause.
Android rewards a few minutes spent in the operating system’s own settings far more than it rewards choosing between clients. If you have not yet worked out whether the phone is where the tunnel belongs, that decision comes first.