Por que o seu aplicativo Android não pode adicionar um perfil de VPN do sistema

Você toca na linha VPN nas Configurações, vê um perfil que outra pessoa instalou e começa a procurar a chamada que adiciona um. Essa chamada não existe. Um aplicativo pode abrir o próprio túnel pelo VpnService, mas as entradas dessa lista pertencem à plataforma e ao cliente que as criou. Saber exatamente onde está a linha economiza uma semana perseguindo classes ocultas.

Comece pelo que a tela de Configurações mostra

A lista de VPN é um registro de perfis que o sistema ou um cliente de fabricante instalou: PPTP, L2TP/IPsec, IKEv2 e as linhas que um aplicativo OEM ou um MDM empurrou. Cada linha carrega um endereço de servidor, credenciais e uma implementação de protocolo que vive fora do seu processo. Quando o usuário toca em Conectar ali, é o cliente da plataforma que levanta o túnel, não o seu código. Por isso a linha sobrevive a uma reinicialização e por isso desinstalar o seu aplicativo nunca a remove.

Do lado do usuário, a lista parece uma superfície de API, um lugar onde adicionar uma VPN deveria estar a um intent de distância. Não está. Os únicos pontos de entrada públicos que a tocam são intents de navegação, e tudo o que escreve nela pertence à plataforma ou a um componente privilegiado.

Consequência prática: se um texto de suporte diz aos usuários para adicionar o perfil nas Configurações, o seu aplicativo não faz parte desse fluxo de jeito nenhum.

O que o VpnService realmente entrega

VpnService e VpnService.Builder descrevem um túnel que pertence ao seu aplicativo. Você adiciona endereços, rotas, servidores DNS e uma MTU, delimita o tráfego com addAllowedApplication() ou addDisallowedApplication(), e então establish() retorna um ParcelFileDescriptor para uma interface TUN. A partir daí o aplicativo lê pacotes IP e escreve respostas, o que significa que o protocolo é seu para implementar ou incorporar: OpenVPN, WireGuard, um transporte próprio.

Nada nessa sequência fala PPTP, L2TP/IPsec ou IKEv2. Builder não tem nenhum interruptor que diga use o cliente L2TP do sistema, e não existe callback que permita conduzir um perfil que a plataforma já possui. Essa é a fronteira real, e é uma fronteira de projeto, não uma lacuna de permissões.

Então um aplicativo pode perfeitamente ser um cliente VPN no Android. Ele só não pode ser um gerenciador dos clientes que vêm com o telefone.

A caixa de consentimento não é decoração

Como o seu túnel pode capturar o tráfego de outros aplicativos, o sistema exige que o usuário o aprove explicitamente. prepare() retorna um Intent que você precisa lançar, a aprovação fica vinculada ao seu pacote, e enquanto o túnel está ativo a barra de status mostra um indicador permanente. Um segundo VPN que sobe desativa o primeiro, porque o Android executa uma VPN ativa por vez.

Essa regra de um só ativo faz gente tropeçar nos testes. Você levanta o seu túnel com um cliente corporativo conectado e conclui que o seu código está quebrado, quando a plataforma apenas trocou de cliente. As aprovações podem ser revogadas depois, e prepare() pode devolver null em aparelhos onde a atividade de consentimento falta, então establish() ainda precisa tratar falhas.

APIs ocultas e intents de configurações

Respostas antigas apontam para classes com.android.internal e interfaces AIDL que o cliente embutido usa. Elas não estão no SDK, mudam entre versões sem aviso e as lojas de aplicativos tratam esse acesso como risco. Fazer root no aparelho também não as torna estáveis, porque root e acesso a APIs ocultas são problemas sem relação.

A ajuda de navegação suportada é Settings.ACTION_VPN_SETTINGS, cujo valor é android.net.vpn.SETTINGS. Resolva-a antes de lançar, porque algumas compilações OEM não incluem essa atividade, e recorra a passos escritos quando a resolução falhar. Ela leva o usuário à tela e não configura nada.

Os caminhos de proprietário do dispositivo e MDM são a exceção que as pessoas costumam querer dizer. O DevicePolicyManager pode designar um pacote de VPN sempre ativa, e as configurações gerenciadas podem pré-carregar ajustes para um cliente que os suporte, mas isso ainda não é o SDK público redigindo um perfil PPTP.

Percorra a decisão do lado do usuário

Se o seu produto precisa transportar tráfego, planeje VpnService mais uma pilha de protocolos real, e reserve tempo para o fluxo de consentimento e a regra da VPN única. Se o objetivo é conectar-se a um perfil corporativo existente, o seu trabalho é orientação: link direto para a tela de configurações, documentar os campos e deixar o cliente da plataforma fazer o túnel. Se o aplicativo só precisa alcançar um endpoint privado, ele não precisa de túnel próprio nenhum.

Escreva essa decisão antes de escrever código, porque os três caminhos quase não têm nada em comum depois do primeiro sprint.

Uma última verificação antes de começar: o requisito diz que o nosso aplicativo se conecta ou que o dispositivo se conecta? O primeiro é VpnService, o segundo é um perfil que você não pode criar. Acertar essa frase custa menos que qualquer refatoração.