Best Android VPN: Keep-Alive, Battery Saving and Split Tunneling Compared

Most people searching for an Android VPN have already tried one or two clients: install, connect, works all day, and then the next morning the connection icon in the notification shade is gone. The problem is rarely the protocol — it is how the system treats a long-running background service. From Doze to background execution limits to each manufacturer's own battery manager, every layer reclaims processes that look idle. This article compares three threads — keep-alive, split tunneling and power draw — and ends with a setup checklist you can follow as written. Every comparison rests on checks you can reproduce; there are no benchmark numbers you cannot verify.

Start by separating two things: whether it connects, and how long it stays connected

A failed connection and a dropped connection are two different problems, and you troubleshoot them in opposite directions. The first is about the protocol, the subscription and whether the route works; the second is about battery policy, background permissions and network handover. Mix the two and you end up in a loop of "I switched three protocols and it still drops."

Drops usually show up in one of three ways. First, after the screen has been off for a while every app times out, then recovers a few seconds after you wake the screen — the system froze the process. Second, walking from indoor Wi-Fi onto mobile data, the connection does not come back on its own and needs a manual reconnect — the long-lived connection died during the handover. Third, the notification icon disappears while system settings still report a connection — usually a leftover tunnel interface, with traffic already back on the local network.

Keep-alive: three layers of settings, and missing one breaks it

Android's power management has three layers: system-level Doze and app standby, app-level background execution limits, and manufacturer battery managers. They operate independently, so doing only one of them usually still leaves you with overnight drops.

1. Add the client to the battery optimization allowlist

   The path is usually Settings → Apps → Special app access → Battery optimization; switch the filter to All apps, find the client and choose Don't optimize. Doze, introduced in Android 6, defers network access and wake-ups once the screen is off, and the allowlist is the most reliable exemption available. Some manufacturers bury this under Battery → App power management with a different name — what you're looking for is a switch like Allow background activity.

2. Enable the manufacturer's autostart and background-running permissions

   Autostart, associated startup and background running go by different names across ROMs but do the same job: whether a process can be brought back after it has been reclaimed. This layer does not affect the foreground service itself, but it decides whether the client can return on its own after being killed.

3. Keep the persistent notification and lock the app in Recents

   A client built on VpnService must run as a foreground service, and the notification is its proof of visibility. If notification permission is revoked, some devices treat the service as invisible and reclaim it sooner, so don't switch it off just to keep the shade tidy. Locking the client in the recent-tasks list also reduces accidental kills during one-tap cleanups.

4. Check that battery saver isn't restricting it separately

   Many systems freeze "rarely used apps" on their own and restrict background data in low-power mode. Add the client to the unrestricted list, then check whether battery saver applies extra limits to background data.

Once all four steps are done, overnight drops usually stop. If they persist, suspect two things first: the system cutting background data wholesale in low-power mode, and a second VpnService-based client installed alongside, fighting for the same slot.

Split tunneling: narrow the tunnel to the apps that need it

Android's VpnService exposes an allow list and a disallow list, and the client uses them to decide which apps go through the tunnel and which stay on the local network — that is split tunneling. It does two things: cuts unnecessary detours to save power, and keeps certain apps from tripping risk controls when the exit region changes.

There are two ways to write the list. The allow list means "proxy only selected apps", so only ticked apps use the tunnel; the disallow list means "exclude selected apps", so everything uses the tunnel by default and you pick out what shouldn't. Day to day, the disallow list is the better default: an allow list easily misses system components, which shows up as a download manager, push or in-app update that works intermittently and takes forever to diagnose. In most clients the entry is called Split tunneling or Per-app proxy.

Power draw: the trade-offs of protocol and heartbeat

Power consumption comes from three places: how often the radio wakes up, encryption overhead, and retransmissions after packet loss. The first is the one most often overlooked — heartbeats and reconnects pull the device out of sleep, and that usually costs more than the crypto itself.

Encryption overhead

Modern ARM processors generally include AES instruction extensions, so AES-family ciphers add very little overhead; where there's no hardware acceleration, a stream cipher such as ChaCha20 is actually cheaper. On Android devices this is rarely the main drain unless the hardware is old or several encrypted connections run at once.

Heartbeats and reconnects

The shorter the heartbeat interval, the less likely an intermediary decides the connection is idle and reclaims it — but the more wake-ups. TCP-based protocols need a fresh handshake after a network change, and reconnecting costs a full connection setup; QUIC-based Hysteria2 and TUIC support connection migration, so they don't re-handshake after a handover and feel smoother on mobile data.

The practical problem with UDP

QUIC-based protocols all run over UDP. Some networks rate-limit UDP or drop it outright, and the client then keeps retransmitting, which can cost more power than TCP. The test is simple: switch protocols on the same route and watch how fast the battery falls and how often it reconnects while the screen is off — keep whichever is steadier.

Protocol and client: the Android comparison

The protocol determines the handshake and transport; the client determines how subscriptions are imported and how split tunneling is configured. Keep the two separate, and don't infer protocol quality from how a client behaves.

On the client side, v2rayNG, NekoBox, the sing-box family and the Clash Meta family all accept subscription links directly. There are two ways to import: copy the subscription URL and choose Import from clipboard in the client, or scan the QR code. A subscription link is a bundle of configuration, not a username and password — re-import the same link on a new device, and update the subscription manually in the client when routes change. Step-by-step instructions are in Guides.

One-week self-check

The checklist below follows the order you'll actually use things in your first week after installing; work through it item by item, no extra tools required.

• ✅ After a night with the screen off, the connection icon is still in the notification shade and overseas sites open without a manual reconnect
• ✅ Switching from Wi-Fi to mobile data and back, the connection recovers within seconds and apps don't need restarting
• ✅ The split-tunneling list matches expectations: excluded apps report a local exit address
• ✅ Tunnelled apps resolve through the DNS specified inside the tunnel, not the local ISP
• ✅ After a subscription update the route list changes as expected, with old configs replaced rather than stacked
• ❌ Notification permission is off, or the client is still in an "optimized" state
• ❌ Two VpnService-based clients are running at once, competing — only one can be active at a time
• ❌ One-tap cleanup kills the app and it doesn't reconnect, and it isn't on any allowlist

Choosing a service: what matters on Android

The order of evaluation on Android differs from desktop. On desktop you start with protocols and client features; on Android you start with route type and how well it cooperates with keep-alive, then look at data allowance and billing.

Route type determines jitter. IEPL dedicated lines, relay and direct connections differ in how many public-network hops sit in the middle: a dedicated line tightens the controllable segment, a relay forwards once at the entry, and a direct connection relies entirely on public routing. Mobile networks are jittery to begin with, so the value of a dedicated line is taking that variable off the table first.

Pick data allowance and billing by how you use it. If you stream often and leave the client running, monthly plans fit better: ¥9.9 a month for 60GB, ¥18 a month for 250GB, ¥28 a month for 500GB, with data resetting monthly on your activation date and mid-cycle upgrades prorated against the remaining days. If you only use it occasionally or while travelling, data packs are better value: ¥158 for 300GB, ¥358 for 1000GB, ¥658 for 3000GB, valid until used up with no expiry.

The sign-up step is worth a look too. VPNLS doesn't require an email address — a username and password are enough — and payment goes through Alipay, WeChat or USDT. The service keeps no logs, which matters more when choosing a provider than one extra protocol.