Android 17 VPN Split Tunneling: What Changes for Users

Split tunneling is one of those VPN features that technically works on Android but practically drives users crazy. Your banking app keeps flagging the connection. Your casting app can't find the TV. You dig through three menus to exclude a single app, only to discover your selections reset the next time the VPN reconnects. Android 17 fixes this not by inventing new functionality, but by pulling the controls into the OS itself.

The Android 17 Beta 3 release notes, published today, describe a new system-managed settings screen that standardizes how VPN apps offer Android 17 VPN split tunneling across the platform. The capability has existed in Android's VPN framework since API level 21, around 2014. What's changing is who owns the interface, and by extension, whether users get a consistent experience regardless of which VPN app they happen to use.

What Android 17's new VPN app exclusion settings actually do

The mechanism is a new intent, ACTION_VPN_APP_EXCLUSION_SETTINGS, which VPN apps invoke to open a single OS-owned screen. From there, users select which apps should bypass the tunnel. Everything else continues routing through the VPN as normal. The interface belongs to Android, not to the VPN developer, per the Beta 3 release notes.

That ownership shift is the whole point. Right now, each VPN developer builds their own split tunneling UI, with their own behavior, in whatever corner of the app they chose. One buries the setting three menus deep. Another requires a manual reconnect before exclusions take effect. A third forgets your selections between sessions. Android Authority noted today that this fragmentation is precisely what the system-managed screen is designed to eliminate.

Part of why the behavior has varied so much comes down to how the underlying API is structured. The VpnService.Builder API supports two mutually exclusive approaches: an allowlist, where only specified apps use the VPN, or a blocklist, where all apps use the VPN except those specified. A builder can use one or the other, but not both, and switching between them throws an exception. VPN developers have implemented these approaches differently, producing experiences that feel like entirely separate features depending on which app you're running. The Android 17 system screen presents a unified interface to users regardless of which method the underlying VPN uses.

Exclusion settings now persist properly, too. Changes take effect immediately if the VPN is already active, or apply automatically the next time it connects, with no manual reconfiguration per session required, per Android Authority.

The users who benefit most are those who routinely need just a handful of apps outside the tunnel:

• Banking apps that flag or block VPN connections
• Local streaming services that break under VPN routing
• Casting apps requiring local network access
• Work apps that misbehave through tunnel routing

For these users, the current situation ranges from fragile to genuinely opaque. A system-managed screen that persists selections and applies them automatically is a meaningful quality-of-life improvement even if nothing about the underlying routing has changed.

What users will actually see, and what they won't

There's an important distinction worth spelling out clearly: this is not a new section in Android Settings that appears for every VPN automatically. The system-managed screen only surfaces when a VPN app explicitly invokes the new intent. If a VPN app hasn't been updated to call ACTION_VPN_APP_EXCLUSION_SETTINGS, its users see nothing different. They get whatever split tunneling experience that app has always offered, buried menus and all.

This is opt-in for developers, not a universal platform change, Android Authority confirmed. The distinction matters because it means rollout will be uneven. Two things must happen before any given user sees this feature: Android 17 needs to land on their device, and their VPN app needs to ship an update that adopts the new intent. Neither is guaranteed on any particular timeline.

That said, the conditions for developer adoption just got meaningfully better. Beta 3 marks Android 17's platform stability milestone, delivering the final SDK and NDK APIs, according to Android Authority's Beta 3 coverage published yesterday. Developers can now build against these interfaces with confidence they won't shift before the stable release. That's the practical starting gun for VPN app updates.

Stable Android 17 is expected in June 2026, initially covering Pixel 6 and newer devices, including Pixel Tablet and Google's foldable lineup, per Android Authority. Watch update changelogs from providers like Proton VPN and NordVPN in the weeks following that release. The system-level VPN split tunneling screen won't appear inside any app that hasn't been updated to invoke it.

The privacy tradeoff users need to understand

The new screen makes split tunneling more accessible. It doesn't change what split tunneling actually does.

Any app excluded from the VPN tunnel sends its traffic over the regular internet connection, fully exposed to the ISP and any network the device is on. The VpnService.Builder documentation is explicit: excluded applications use networking as if no VPN were running at all. That's the tradeoff, and a cleaner interface doesn't soften it. The responsibility for deciding which apps to exclude, and understanding the exposure that creates, remains with the user.

The Android 17 system-level split tunneling feature also doesn't resolve one known edge case that's been in the API documentation for years. When an HTTP proxy is combined with a split tunnel, the behavior becomes unreliable. Apps using the proxy can't distinguish which routes the VPN handles, so they attempt to route HTTP traffic through the proxy regardless of destination. This breaks because the proxy isn't reachable outside the VPN network, as the VpnService.Builder docs note. Users in complex network configurations, corporate environments being the obvious example, should treat the new interface as a UX improvement and not assume it resolves deeper routing complications.

What this means for the VPN app ecosystem

Android 17's system-managed screen shifts something more than just the user experience. It shifts where the implementation burden sits.

Under the current model, every VPN developer who wants to offer split tunneling must build and maintain their own UI, handle session persistence, and decide when exclusions take effect. That's why the results vary so widely. With Android 17, developers who adopt the new intent hand off that responsibility to the OS. The interface, the persistence, the timing Google handles it. The VPN app just needs to point users at the system screen.

That's a reasonable incentive to update. For major providers like NordVPN and Proton VPN, which already support split tunneling in some form, adopting the new intent means replacing a custom implementation they have to maintain with one they don't. Smaller providers who never built the feature at all get it for free. The question is whether the ecosystem moves quickly or slowly and history suggests Android feature adoption varies considerably depending on how much work developers have to undo first.

The bottom line

Android 17's approach to VPN split tunneling is a genuine UX upgrade, not a feature launch. The underlying API has supported app-level exclusions since 2014, per the VpnService.Builder documentation. What the Beta 3 release notes describe is a consistent, OS-managed interface replacing a decade's worth of inconsistent app-specific implementations.

Platform stability landed with Beta 3 yesterday. The stable release is three months out. Real-world adoption will depend entirely on how fast major VPN providers ship updates invoking the new screen. Google has done its part. Whether this becomes the consistent experience it's designed to be, rather than one more layer stacked on top of the old fragmentation, comes down to whether the apps follow.