Android VPN vs App Permissions: What the Warning Means

Two Android dialogs get conflated all the time: the VPN consent prompt and the permission requests an app makes for your data. The first hands over a network position, the spot where packets can be read and rewritten. The second hands over stored content that Android guards app by app. Treating them as one thing either exaggerates what a tunnel can see or badly understates what a determined app will ask for next.

What the consent dialog actually hands over

An app that implements VpnService and declares BIND_VPN_SERVICE asks the system to become the device VPN. On approval the framework creates a tun interface and gives the app a file descriptor for it. Everything the app does afterwards flows through that descriptor: it reads IP packets out, decides what to do with them, and writes packets back in.

The scope of that interface is explicit. Routes decide which destinations are captured, and addAllowedApplication or addDisallowedApplication decides which apps feed it. A per-app VPN that lists two apps does not see the rest of the device.

That is a packet-level grant, not a data-level one. The service sees the bytes an app hands to the network stack, addressed to a destination. It does not get a handle on the sending app private storage, its database files or its decrypted memory. Files an app saved under its own sandbox stay exactly as hard to read as before.

Where the packet view stops

TLS still does its job inside the tunnel, because the handshake runs between the app and the server rather than between the app and the VPN. The VPN forwards ciphertext it cannot decrypt without the session keys. That is why a tunnel alone does not reveal the contents of an HTTPS page or a protected mail session.

The metadata around the ciphertext is a different story, and this is where most confident claims fall apart. Destination IP, port, packet sizes and timing are all visible, plus the server name in the TLS ClientHello, which is normally sent in the clear even under TLS 1.3. Encrypted Client Hello changes that, but it is not universal. Plain DNS leaks names just as readily when queries go out unencrypted.

Older or misconfigured protocols hand over more. Plain HTTP, IMAP without TLS and a number of game and IoT protocols expose their payloads to anything holding the tun descriptor.

The permissions that never come with it

Approving a VPN does not approve contacts, SMS, photos or the media store. Those are separate runtime grants, each with its own dialog and its own revocation path in the app settings page. A VPN client that wants your call log has to ask for it like any other app, and you can refuse while keeping the tunnel.

Certificate installation is the one to watch, because it looks like part of VPN setup and is not. Installing a user CA into the credential store changes which certificates Android will accept, and since Android 7.0 an app targeting API 24 or later ignores user-added CAs unless its network security config opts in with a user trust anchor. A client that insists on a CA may be doing legitimate enterprise interception, or it may be asking for something the VPN dialog never mentioned.

Accessibility access sits even further out. A service with accessibility enabled can read the screen content of other apps, which no packet-level position provides.

Local filter or remote gateway

The same API covers two products that deserve different levels of trust. An on-device firewall or ad blocker takes the tun descriptor and answers the traffic locally, never sending it to a server it operates. A real tunnel forwards those packets to a gateway somewhere else, and that operator sees the same metadata from the other end while also deciding what comes back.

A practical way to tell them apart is to check your public address with the VPN on and off, and to look at whether the notification names a remote endpoint. If the address never changes, the traffic is probably looping back on the device.

Both cases are still a packet position. The difference is who else is standing at the exit.

Audit what you approved

Open Settings, then Network and internet, then VPN, and read the entry rather than the icon in the status bar. Always-on VPN and Block connections without VPN are device settings that keep the interface alive and cut leaks; they widen nothing. From the same screen you can forget the profile and revoke the grant.

Then walk the other permissions. App info shows which runtime grants the client holds, and Security settings shows whether a user certificate was installed at the same time. Either one can be removed independently.

The question worth answering is narrow: which packets enter this service, where do they go, and what does the implementation keep. Everything else in the dialog is noise. The VpnService reference is the authoritative list of what the interface exposes.