Hvorfor Android-appen din ikke kan legge til en system-VPN-profil

Du trykker på VPN-raden i Innstillinger, ser en profil noen andre har installert, og begynner å lete etter kallet som legger til en. Det finnes ikke noe slikt kall. En app kan åpne sin egen tunnel via VpnService, men oppføringene i den listen tilhører plattformen og den klienten som laget dem. Å vite nøyaktig hvor grensen går sparer deg en uke med jakt på skjulte klasser.

Start med det Innstillinger-skjermen viser

VPN-listen er et register over profiler som systemet eller en leverandørklient har installert: PPTP, L2TP/IPsec, IKEv2 og radene en OEM-app eller en MDM har dyttet inn. Hver rad bærer en serveradresse, påloggingsdetaljer og en protokollimplementasjon som lever utenfor prosessen din. Når brukeren trykker Koble til der, er det plattformens klient som reiser tunnelen, ikke koden din. Derfor overlever raden en omstart, og derfor fjerner avinstallering av appen din den aldri.

Fra brukerens side ser listen ut som en API-flate, et sted der det å legge til en VPN burde være én intent unna. Det er den ikke. De eneste offentlige inngangspunktene som berører den, er navigasjonsintents, og alt som skriver til den, tilhører plattformen eller en privilegert komponent.

Praktisk konsekvens: hvis en støttetekst ber brukerne legge til profilen i Innstillinger, er appen din ikke en del av den flyten i det hele tatt.

Hva VpnService faktisk gir deg

VpnService og VpnService.Builder beskriver én tunnel som appen din eier. Du legger til adresser, ruter, DNS-servere og en MTU, avgrenser trafikken med addAllowedApplication() eller addDisallowedApplication(), og så returnerer establish() en ParcelFileDescriptor for et TUN-grensesnitt. Fra det punktet leser appen IP-pakker og skriver svar, som betyr at protokollen er din å implementere eller bygge inn: OpenVPN, WireGuard, en egen transport.

Ingenting i den sekvensen snakker PPTP, L2TP/IPsec eller IKEv2. Builder har ingen bryter som sier bruk systemets L2TP-klient, og det finnes ingen callback som lar deg styre en profil plattformen allerede eier. Det er den virkelige grensen, og det er en designgrense, ikke et hull i tillatelsene.

Så en app kan absolutt være en VPN-klient på Android. Den kan bare ikke være administrator for klientene som følger med telefonen.

Samtykkedialogen er ikke pynt

Fordi tunnelen din kan fange trafikken til andre apper, krever systemet at brukeren godkjenner den uttrykkelig. prepare() returnerer et Intent du må starte, godkjenningen er knyttet til pakken din, og mens tunnelen er oppe viser statuslinjen en fast indikator. En andre VPN som kommer opp, deaktiverer den første, fordi Android kjører én aktiv VPN om gangen.

Den regelen om én aktiv får folk til å snuble i testing. Du reiser tunnelen din mens en bedriftsklient er tilkoblet og konkluderer med at koden din er ødelagt, mens plattformen bare byttet bort fra den andre klienten. Godkjenninger kan trekkes tilbake senere, og prepare() kan returnere null på enheter der samtykkeaktiviteten mangler, så establish() må fortsatt håndtere feil.

Skjulte API-er og innstillingsintents

Eldre svar peker på com.android.internal-klasser og AIDL-grensesnitt som den innebygde klienten bruker. De er ikke i SDK-en, de endres mellom utgivelser uten varsel, og app-butikker ser på den tilgangen som en risiko. Å roote enheten gjør dem heller ikke stabile, fordi root og tilgang til skjulte API-er er uavhengige problemer.

Den støttede navigasjonshjelpen er Settings.ACTION_VPN_SETTINGS, hvis verdi er android.net.vpn.SETTINGS. Slå den opp før du starter den, fordi noen OEM-bygg ikke leverer den aktiviteten, og fall tilbake til skrevne trinn når oppslaget feiler. Den fører brukeren til skjermen og konfigurerer ingenting.

Enhetseier- og MDM-veier er unntaket folk vanligvis mener. DevicePolicyManager kan utpeke en alltid-på VPN-pakke, og administrerte konfigurasjoner kan forhåndslaste innstillinger for en klient som støtter dem, men det er fortsatt ikke den offentlige SDK-en som skriver en PPTP-profil.

Gå beslutningen fra brukerens side

Hvis produktet ditt må bære trafikk, planlegg VpnService pluss en ekte protokollstakk, og sett av tid til samtykkeflyten og regelen om én VPN. Hvis målet er å koble til en eksisterende bedriftsprofil, er jobben din veiledning: dyp lenke til innstillingene, dokumenter feltene, og la plattformens klient gjøre tunneleringen. Hvis appen bare trenger å nå et privat endepunkt, trenger den ingen egen tunnel i det hele tatt.

Skriv ned den beslutningen før du skriver kode, fordi de tre veiene har nesten ingenting til felles etter den første sprinten.

En siste sjekk før du begynner: sier kravet at appen vår kobler til, eller at enheten kobler til? Det første er VpnService, det andre er en profil du ikke kan lage. Å få den setningen riktig er billigere enn enhver refaktorering.