Por que a túa aplicación de Android non pode engadir un perfil de VPN do sistema

Tocas a fila de VPN en Axustes, ves un perfil que instalou outra persoa e comezas a buscar a chamada que engade un. Esa chamada non existe. Unha aplicación pode abrir un túnel propio mediante VpnService, pero as entradas desa lista pertencen á plataforma e ao cliente que as creou. Saber exactamente onde está a liña aforra unha semana perseguindo clases ocultas.

Comeza polo que amosa a pantalla de Axustes

A lista de VPN é un rexistro de perfís que instalou o sistema ou un cliente dun fabricante: PPTP, L2TP/IPsec, IKEv2 e as filas que empuxase unha aplicación OEM ou un MDM. Cada fila leva un enderezo de servidor, credenciais e unha implementación de protocolo que vive fóra do teu proceso. Cando o usuario toca Conectar alí, o cliente da plataforma levanta o túnel, non o teu código. Por iso a fila sobrevive a un reinicio e por iso desinstalar a túa aplicación nunca a elimina.

Desde o lado do usuario a lista parece unha superficie de API, un lugar onde engadir unha VPN debería estar a un intent de distancia. Non o é. Os únicos puntos de entrada públicos que a tocan son intents de navegación, e todo o que escribe nela pertence á plataforma ou a un compoñente privilexiado.

Consecuencia práctica: se un guión de asistencia di aos usuarios que engadan o perfil en Axustes, a túa aplicación non forma parte dese fluxo en absoluto.

O que VpnService che dá de verdade

VpnService e VpnService.Builder describen un túnel que posúe a túa aplicación. Engades enderezos, rutas, servidores DNS e unha MTU, delimitas o tráfico con addAllowedApplication() ou addDisallowedApplication(), e despois establish() devolve un ParcelFileDescriptor para unha interface TUN. A partir de aí a aplicación le paquetes IP e escribe respostas, o que significa que o protocolo é teu para implementalo ou incrustalo: OpenVPN, WireGuard, un transporte propio.

Nada nesa secuencia fala PPTP, L2TP/IPsec nin IKEv2. Builder non ten ningún conmutador que diga usa o cliente L2TP do sistema, e non hai ningunha devolución de chamada que che permita conducir un perfil que a plataforma xa posúe. Esa é a fronteira real, e é unha fronteira de deseño, non un oco de permisos.

Así que unha aplicación pode ser sen dúbida un cliente VPN en Android. Só que non pode ser un xestor dos clientes que veñen co teléfono.

O diálogo de consentimento non é decoración

Como o teu túnel pode capturar o tráfico doutras aplicacións, o sistema obriga a que o usuario o aprobe explicitamente. prepare() devolve un Intent que debes lanzar, a aprobación está ligada ao teu paquete, e mentres o túnel está activo a barra de estado mostra un indicador permanente. Un segundo VPN que se levante desactiva o primeiro, porque Android executa unha VPN activa á vez.

Esa regra de só un activo fai tropezar a xente nas probas. Levantas o teu túnel mentres hai un cliente corporativo conectado e conclúes que o teu código está roto, cando a plataforma simplemente cambiou de cliente. As aprobacións pódense revogar despois, e prepare() pode devolver null en dispositivos onde falta a actividade de consentimento, así que establish() segue tendo que xestionar o fallo.

API ocultas e intents de axustes

As respostas antigas apuntan a clases com.android.internal e interfaces AIDL que usa o cliente integrado. Non están no SDK, cambian entre versións sen aviso e as tendas de aplicacións tratan ese acceso como un risco. Facer root no dispositivo tampouco as volve estables, porque root e acceso a API ocultas son problemas non relacionados.

A axuda de navegación soportada é Settings.ACTION_VPN_SETTINGS, cuxo valor é android.net.vpn.SETTINGS. Resólvea antes de lanzala, porque algunhas compilacións OEM non inclúen esa actividade, e recorre a pasos escritos cando a resolución falla. Leva o usuario á pantalla e non configura nada.

Os camiños de propietario do dispositivo e MDM son a excepción que a xente adoita querer dicir. DevicePolicyManager pode designar un paquete de VPN sempre activa, e as configuracións xestionadas poden precargar axustes para un cliente que os admita, pero iso segue sen ser o SDK público redactando un perfil PPTP.

Percorre a decisión desde o lado do usuario

Se o teu produto ten que transportar tráfico, planifica VpnService máis unha pila de protocolos real, e orzamenta tempo para o fluxo de consentimento e a regra dunha soa VPN. Se o obxectivo é conectarse a un perfil corporativo existente, o teu traballo é guiar: ligazón profunda á pantalla de axustes, documenta os campos e deixa que o cliente da plataforma faga o túnel. Se a aplicación só necesita chegar a un punto final privado, non necesita ningún túnel propio.

Escribe esa decisión antes de escribir código, porque os tres camiños non teñen case nada en común despois do primeiro sprint.

Unha última comprobación antes de comezar: o requisito di que se conecta a nosa aplicación ou que se conecta o dispositivo? O primeiro é VpnService, o segundo é un perfil que non podes crear. Acertar esa frase é máis barato que calquera refactorización.