Per què la teva aplicació d'Android no pot afegir un perfil de VPN del sistema

Toques la fila de VPN a Configuració, veus un perfil que ha instal·lat una altra persona i comences a buscar la crida que n'afegeix un. Aquesta crida no existeix. Una aplicació pot obrir un túnel propi mitjançant VpnService, però les entrades d'aquella llista pertanyen a la plataforma i al client que les va crear. Saber exactament on és la línia t'estalvia una setmana perseguint classes ocultes.

Comença pel que mostra la pantalla de Configuració

La llista de VPN és un registre de perfils que ha instal·lat el sistema o un client d'un fabricant: PPTP, L2TP/IPsec, IKEv2 i les files que hagi empès una aplicació OEM o un MDM. Cada fila porta una adreça de servidor, credencials i una implementació de protocol que viu fora del teu procés. Quan l'usuari toca Connecta allà, el client de la plataforma aixeca el túnel, no el teu codi. Per això la fila sobreviu a un reinici i per això desinstal·lar la teva aplicació no l'elimina mai.

Des del punt de vista de l'usuari, la llista sembla una superfície d'API, un lloc on afegir una VPN hauria de ser un intent de distància. No ho és. Els únics punts d'entrada públics que la toquen són intents de navegació, i tot el que hi escriu pertany a la plataforma o a un component privilegiat.

Conseqüència pràctica: si un guió d'assistència diu als usuaris que afegeixin el perfil a Configuració, la teva aplicació no forma part d'aquell flux en absolut.

Què et dona realment VpnService

VpnService i VpnService.Builder descriuen un túnel que posseeix la teva aplicació. Afegeixes adreces, rutes, servidors DNS i una MTU, delimites el trànsit amb addAllowedApplication() o addDisallowedApplication(), i després establish() retorna un ParcelFileDescriptor per a una interfície TUN. A partir d'aquí l'aplicació llegeix paquets IP i escriu respostes, cosa que vol dir que el protocol és teu per implementar-lo o incrustar-lo: OpenVPN, WireGuard, un transport propi.

Res d'aquesta seqüència no parla PPTP, L2TP/IPsec ni IKEv2. Builder no té cap commutador que digui fes servir el client L2TP del sistema, i no hi ha cap retorn de trucada que et permeti conduir un perfil que la plataforma ja posseeix. Aquesta és la frontera real, i és una frontera de disseny, no un buit de permisos.

Així que una aplicació pot ser sens dubte un client VPN a Android. Només no pot ser un gestor dels clients que venen amb el telèfon.

El diàleg de consentiment no és decoració

Com que el teu túnel pot capturar el trànsit d'altres aplicacions, el sistema fa que l'usuari l'aprovi explícitament. prepare() retorna un Intent que has de llançar, l'aprovació està lligada al teu paquet, i mentre el túnel és actiu la barra d'estat mostra un indicador permanent. Un segon VPN que s'aixeca desactiva el primer, perquè Android executa una VPN activa alhora.

Aquesta regla d'un sol actiu fa ensopegar la gent a les proves. Aixeques el teu túnel mentre un client corporatiu està connectat i conclous que el teu codi està trencat, quan la plataforma simplement ha canviat de client. Les aprovacions es poden revocar més tard, i prepare() pot retornar null en dispositius on falta l'activitat de consentiment, així que establish() encara ha de gestionar el fracàs.

API ocultes i intents d'ajustos

Les respostes antigues apunten a classes com.android.internal i interfícies AIDL que fa servir el client integrat. No són a l'SDK, canvien entre versions sense avís i les botigues d'aplicacions tracten aquest accés com un risc. Fer root al dispositiu tampoc no les fa estables, perquè root i accés a API ocultes són problemes no relacionats.

L'ajuda de navegació suportada és Settings.ACTION_VPN_SETTINGS, el valor de la qual és android.net.vpn.SETTINGS. Resol-la abans de llançar-la, perquè algunes compilacions OEM no inclouen aquesta activitat, i recorre a passos escrits quan la resolució falla. Porta l'usuari a la pantalla i no configura res.

Els camins de propietari del dispositiu i MDM són l'excepció que la gent sol voler dir. DevicePolicyManager pot designar un paquet de VPN sempre actiu, i les configuracions gestionades poden precarregar ajustos per a un client que els admeti, però això encara no és l'SDK públic redactant un perfil PPTP.

Recorre la decisió des del costat de l'usuari

Si el teu producte ha de transportar trànsit, planifica VpnService més una pila de protocols real, i pressuposta temps per al flux de consentiment i la regla d'una sola VPN. Si l'objectiu és connectar-se a un perfil corporatiu existent, la teva feina és guiar: enllaç profund a la pantalla d'ajustos, documenta els camps i deixa que el client de la plataforma faci el túnel. Si l'aplicació només ha d'arribar a un punt final privat, no necessita cap túnel propi.

Escriu aquesta decisió abans d'escriure codi, perquè els tres camins no tenen gairebé res en comú després del primer sprint.

Una última comprovació abans de començar: el requisit diu que s'hi connecta la nostra aplicació o que s'hi connecta el dispositiu? El primer és VpnService, el segon és un perfil que no pots crear. Encertar aquesta frase és més barat que qualsevol refactorització.