Ask for an Android VPN recommendation and the usual answer comes down to server count and price. But most Android disconnects have nothing to do with servers: the system's battery saver reclaims the client process in the background, the tunnel closes with it, and the connection is gone a few minutes after the screen locks. This comparison therefore focuses on three Android-specific things — keep-alive, battery whitelists and split tunneling.
The rest of this guide breaks the three areas down one by one: first what actually happens at the system level, then setup paths you can follow tap by tap, then a checklist you can tick off item by item, and finally a troubleshooting sequence to work through in order. Menu names follow the common builds of major vendor ROMs; exact wording may differ slightly between OS versions.
Android Drops More Often: Battery Saver Gets There First
On desktop systems, the tunnel stays up as long as the client process is running. Android is different: to save power, the system does two things to background apps — it limits wake-ups and network access, and it reclaims processes when memory runs low. Stock Android handles this through Doze and App Standby; vendor ROMs add another layer of background management on top, usually more aggressive than stock, which is the main reason the same client behaves differently on different phones.
On Android, a network acceleration client relies on the system's VpnService: it creates a virtual network interface (tun), and traffic that needs the tunnel goes in and out through it. The tunnel has to be kept alive by a persistent process; if that process is frozen or killed, the connection drops. The keep-alive method the system recognises is a foreground service plus a persistent notification — the ongoing notification with the VPN icon in the status bar is the sign that the tunnel is still running.
One more behaviour that is easily mistaken for a broken client: the first time you connect, the system shows a VPN connection request that you have to confirm. That is VpnService's security design, and after you authorise once it stops asking. If you have to confirm every single time, the authorisation is not being remembered, which usually points to the Always-on VPN configuration or to system cleanup.
Three Android-Specific Areas: Keep-Alive, Battery Whitelists, Split Tunneling
Android stability breaks down into three areas you can check one by one.
- Keep-alive: whether the client runs as a foreground service, whether its notification stays put, and whether it offers auto-reconnect and a heartbeat interval setting.
- Battery whitelist: whether the system lists the client as Unrestricted, and whether the vendor ROM's autostart, associated startup and background running switches are all allowed.
- Split tunneling: which apps' traffic enters the tunnel and which goes direct is decided by VpnService's allow list or exclude list.
The three areas cover different problems. The table below lines them up with the symptoms you'll see:
| Symptom | System-level cause | Where to fix it |
|---|---|---|
| Connection drops a few minutes after the screen locks | Doze freezes the background process and suspends network access | Battery optimization whitelist + client keep-alive switch |
| No automatic reconnect after a phone restart | The vendor ROM blocked autostart | Autostart management / background running permission |
| The ongoing notification disappears while the app still shows Connected | The foreground service was demoted or ended by the system | Restore the ongoing notification; don't swipe it away |
| Domestic apps slow down, payment apps report errors | All traffic enters the tunnel; exit IP and account region don't match | Switch to split tunneling or rule mode |
| The client says Connected but pages still won't load | DNS resolution still goes through the local resolver | Turn on remote DNS / leak protection |
Of the three, keep-alive decides whether the connection can hold, the battery whitelist decides whether it can hold all day, and split tunneling decides how usable it is once it holds. Check only one and your troubleshooting usually stalls halfway.
Battery Whitelist and Keep-Alive Settings: Step by Step Through the System Menus
This sequence works on stock Android and on the major vendor ROMs. Work through steps 1 to 5 in order — don't skip any.
- Allow background battery use: Settings → Apps → find the client → Battery (or Battery usage), and change the policy from Smart restriction or Optimized to Unrestricted.
- Add it to the battery optimization whitelist: Settings → Battery → Battery optimization → All apps → find the client → choose Don't optimize. On stock Android 12 and later the entry point is Settings → Apps → Special app access → Battery optimization.
- Clear the vendor's background management: on MIUI / HyperOS, allow autostart under App settings → Apps → Permissions → Autostart and set Battery saver policy to No restrictions; on ColorOS, allow Autostart, Associated startup and Background running one by one under App management; on OriginOS, add the client to the High background power consumption whitelist; on HarmonyOS, turn off automatic management under App launch management and switch on Autostart, Associated startup and Background activity manually; on Samsung, set Background usage limits under Battery to Unrestricted.
- Lock it in Recents: in the multitasking view, pull down on the client card or tap the lock icon so a one-tap clear doesn't take it out with everything else.
- Check battery saver and deep sleep: turn off the system battery saver, and under Battery → More settings confirm the client isn't on the Deep sleep or Smart power saving restricted list.
To confirm the system really is letting it through, you can check the Doze whitelist over USB debugging:
adb shell dumpsys deviceidle whitelist
# If the client package name appears in the output, the client is on the Doze whitelistTo add one manually, the command is adb shell dumpsys deviceidle whitelist +package.name; to remove it, swap the plus for a minus. This step is an optional check — you don't need to do it every time.
Split Tunneling: Which Apps Use the Tunnel and Which Stay Direct
Split tunneling is a capability VpnService provides: the client decides where traffic goes using an allow list (only apps on the list are proxied) or an exclude list (apps not on the list enter the tunnel). Android allows only one active VPN service at a time, so split tunneling has to be handled by whichever client is currently connected — you can't split the job between two clients.
For Android users, split tunneling solves two concrete problems. First, keeping domestic apps on a direct connection saves a detour: food delivery, ride hailing, maps and local video services are already local, and routing them through the tunnel only makes them slower. Second, payment and banking apps are sensitive to changes in IP location, and a frequently switching exit can trip their risk controls — putting them on the direct list saves trouble.
Two groups you can copy
- Through the tunnel: browsers and search, AI assistant apps, overseas video and music, overseas work apps (Teams, Slack and the like), and the app store when you need to download apps from an overseas region.
- Direct: payments and banking, food delivery and ride hailing, maps and navigation, domestic video and music, and smart home and push notification apps.
If a client only offers rule mode and no split tunneling, domain and IP rules get you close: traffic that matches a rule enters the tunnel, everything else goes direct. Global mode is fine for a quick test — it tells you fast whether the routing rules are the problem — but it isn't meant to stay on long term.
Android Checklist: Eight Items to Tick Off
Here's the above distilled into a checklist — run through it item by item when you pick a client or switch services. The first six are pluses; the last two are clear minuses.
- ✅ Uses the system VpnService: one authorization prompt on first connect, no repeated confirmations after that.
- ✅ Runs as a foreground service with an ongoing notification, and offers an auto-reconnect switch.
- ✅ Supports split tunneling, with at least an allow list or an exclude list.
- ✅ Has a remote DNS or leak protection switch in the app instead of relying entirely on the system DNS.
- ✅ Switchable protocols, covering two or more of Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC.
- ✅ Simple subscription import: copy the subscription URL, paste, update nodes — no filling in parameters by hand.
- ❌ A client that talks about battery optimization but has no keep-alive settings will struggle to stay connected overnight on vendor ROMs.
- ❌ A client with only global mode and no routing at all means you'll keep bouncing between detours and dead connections in daily use.
One more thing worth noting beyond the checklist: the subscription link has to be updatable at any time. When nodes change, whether the client can refresh the subscription in one tap — and whether it keeps your split tunneling and keep-alive settings afterwards — decides how much fiddling long-term use costs you.
Troubleshooting Order: From System Settings to Client Logs
When a connection drops, work through the order below — you can usually pin down the cause in a few steps.
- Check the connection timer: back in the client, a timer reset to zero means the tunnel dropped; if the timer is still counting but apps won't load, the problem is more likely routing or DNS.
- Check battery optimization: after a system update, apps are sometimes put back on the Optimized list — go back into settings and confirm.
- Check the vendor's background management: see whether Smart power saving has switched autostart and background running back off.
- Look at the status bar: is the ongoing notification still there? If it's gone but the app still shows Connected, the foreground service may have been demoted by the system.
- Compare networks: try Wi-Fi and mobile data once each. On mobile, carrier NAT reclaims long-idle connections, so a client with a long heartbeat interval looks like it reconnects every so often.
- Switch protocol or server: on a lossy network, the QUIC-based Hysteria2 and TUIC usually recover faster than plain TCP protocols; switching servers rules out a problem on the server side.
- Finally, read the logs: clients usually keep a connection log that records why a reconnect happened — use it and go back to step 1.
Conclusion: What Android Users Should Pick
Back to the opening question: what standard should you use on Android? Put the three areas together and the answer is far more concrete than a plain server-count comparison.
For Android users the priority order is keep-alive, battery whitelist, split tunneling. A client with complete keep-alive settings cuts most of the surprise reconnects on the same server; a client with proper split tunneling makes the biggest everyday difference. Server count and price come after those three — get the order wrong and the service you pick tends to fall apart the moment the screen locks.
If you'd rather not compare item by item, here are the checkable facts: MeyeVPN covers 100+ countries with 190+ routes, unlimited devices, no email address required to sign up, military-grade encryption in transit, and a 30-day money-back guarantee.
The last step on Android is to walk through the setup order in section 3 on your own phone, then run the troubleshooting order in section 6 once. After those two, connection stability is mostly decided by the quality of the route rather than by the system's battery saver.