Warum Ihre Android-App kein System-VPN-Profil hinzufügen kann

Sie tippen in den Einstellungen auf die VPN-Zeile, sehen ein Profil, das jemand anderes installiert hat, und beginnen, nach dem Aufruf zu suchen, der eines hinzufügt. Diesen Aufruf gibt es nicht. Eine App kann über VpnService einen eigenen Tunnel öffnen, aber die Einträge in dieser Liste gehören der Plattform und dem jeweiligen Client, der sie angelegt hat. Genau zu wissen, wo die Grenze verläuft, erspart Ihnen eine Woche Jagd auf versteckte Klassen.

Beginnen Sie mit dem, was der Bildschirm Einstellungen zeigt

Die VPN-Liste ist ein Register der Profile, die das System oder ein Herstellerclient installiert hat: PPTP, L2TP/IPsec, IKEv2 und alle Zeilen, die eine OEM-App oder ein MDM eingeschoben hat. Jede Zeile trägt eine Serveradresse, Zugangsdaten und eine Protokollimplementierung, die außerhalb Ihres Prozesses lebt. Wenn der Nutzer dort auf Verbinden tippt, baut der Client der Plattform den Tunnel auf, nicht Ihr Code. Deshalb überlebt die Zeile einen Neustart, und deshalb entfernt das Deinstallieren Ihrer App sie nie.

Aus Sicht des Nutzers sieht die Liste wie eine API-Oberfläche aus, ein Ort, an dem das Hinzufügen eines VPN nur einen Intent entfernt sein sollte. Ist sie nicht. Die einzigen öffentlichen Einstiegspunkte, die sie berühren, sind Navigations-Intents, und alles, was hineinschreibt, gehört der Plattform oder einer privilegierten Komponente.

Praktische Folge: Wenn ein Supporttext den Nutzern sagt, sie sollen das Profil in den Einstellungen hinzufügen, ist Ihre App überhaupt nicht Teil dieses Ablaufs.

Was VpnService Ihnen tatsächlich gibt

VpnService und VpnService.Builder beschreiben einen Tunnel, den Ihre App besitzt. Sie fügen Adressen, Routen, DNS-Server und eine MTU hinzu, grenzen den Verkehr mit addAllowedApplication() oder addDisallowedApplication() ein, und dann liefert establish() einen ParcelFileDescriptor für ein TUN-Interface. Ab diesem Punkt liest die App IP-Pakete und schreibt Antworten, was bedeutet, dass das Protokoll Ihre Sache ist: OpenVPN, WireGuard, ein eigener Transport.

Nichts in dieser Reihenfolge spricht PPTP, L2TP/IPsec oder IKEv2. Builder hat keinen Schalter, der sagt, nutze den System-L2TP-Client, und es gibt keinen Callback, mit dem Sie ein Profil steuern könnten, das die Plattform bereits besitzt. Das ist die eigentliche Grenze, und es ist eine Designgrenze, keine Lücke bei den Berechtigungen.

Eine App kann auf Android also durchaus ein VPN-Client sein. Sie kann nur kein Verwalter für die Clients sein, die mit dem Telefon ausgeliefert werden.

Der Zustimmungsdialog ist keine Dekoration

Weil Ihr Tunnel den Verkehr anderer Apps abfangen kann, verlangt das System, dass der Nutzer ihn ausdrücklich genehmigt. prepare() liefert einen Intent, den Sie starten müssen, die Genehmigung ist an Ihr Paket gebunden, und solange der Tunnel läuft, zeigt die Statusleiste einen dauerhaften Hinweis. Ein zweites VPN, das hochkommt, deaktiviert das erste, denn Android betreibt immer nur ein aktives VPN.

Diese Regel des einen aktiven VPN bringt Leute beim Testen aus dem Tritt. Sie bauen Ihren Tunnel auf, während ein Firmenclient verbunden ist, und schließen, dass Ihr Code kaputt ist, dabei hat die Plattform einfach vom anderen Client weggeschaltet. Genehmigungen lassen sich später widerrufen, und prepare() kann null zurückgeben auf Geräten, denen die Zustimmungsaktivität fehlt, also muss establish() weiterhin Fehler behandeln.

Versteckte APIs und Einstellungs-Intents

Ältere Antworten verweisen auf com.android.internal-Klassen und AIDL-Schnittstellen, die der eingebaute Client nutzt. Sie sind nicht im SDK, sie ändern sich zwischen Releases ohne Vorankündigung, und App-Stores werten diesen Zugriff als Risiko. Ein gerootetes Gerät macht sie auch nicht stabil, denn Root und Zugriff auf versteckte APIs sind unabhängige Probleme.

Die unterstützte Navigationshilfe ist Settings.ACTION_VPN_SETTINGS, deren Wert android.net.vpn.SETTINGS ist. Lösen Sie sie vor dem Start auf, weil manche OEM-Builds diese Aktivität nicht mitliefern, und weichen Sie auf geschriebene Schritte aus, wenn die Auflösung scheitert. Sie bringt den Nutzer zum Bildschirm und konfiguriert nichts.

Device-Owner- und MDM-Wege sind die Ausnahme, die Leute meistens meinen. DevicePolicyManager kann ein Always-on-VPN-Paket festlegen, und verwaltete Konfigurationen können Einstellungen für einen Client vorladen, der sie unterstützt, aber das ist immer noch nicht das öffentliche SDK, das ein PPTP-Profil verfasst.

Gehen Sie die Entscheidung aus Nutzersicht durch

Wenn Ihr Produkt Verkehr transportieren soll, planen Sie VpnService plus einen echten Protokollstapel ein und kalkulieren Sie Zeit für den Zustimmungsablauf und die Ein-VPN-Regel. Wenn das Ziel ist, sich mit einem bestehenden Firmenprofil zu verbinden, ist Ihre Aufgabe die Führung: Deep-Link zum Einstellungsbildschirm, die Felder dokumentieren, und den Tunnel den Plattform-Client machen lassen. Wenn die App nur einen privaten Endpunkt erreichen muss, braucht sie überhaupt keinen eigenen Tunnel.

Schreiben Sie diese Entscheidung auf, bevor Sie Code schreiben, denn die drei Wege haben nach dem ersten Sprint fast nichts gemeinsam.

Eine letzte Prüfung, bevor Sie anfangen: Sagt die Anforderung, dass unsere App sich verbindet, oder dass das Gerät sich verbindet? Das erste ist VpnService, das zweite ist ein Profil, das Sie nicht anlegen können. Diesen Satz richtig zu formulieren ist billiger als jedes Refactoring.