Android: Always-On e bloqueio sem VPN — escolha o par certo

Always-On e bloqueio sem VPN são dois ajustes e ativar o primeiro não ativa o segundo. O par depende de quem é dono do aparelho, quais apps o túnel cobre e o que acontece antes do desbloqueio.

Dois interruptores com promessas diferentes

O Always-On promete persistência e reinicia o serviço quando ele cai; o bloqueio promete confinamento: sem túnel, o tráfego coberto não tem saída.

O terceiro fator é o escopo por app, que pertence ao cliente ou à política de gestão, não aos dois interruptores do sistema; bloquear sem decidir o escopo gera uma política mais ampla ou mais estreita que a necessidade.

Primeira decisão: aparelho gerenciado ou ajuste do usuário?

Em um aparelho gerenciado a política controla Always-On e bloqueio, e o interruptor local pode faltar; mude o requisito na política, não no aparelho.

Em um aparelho pessoal o usuário decide se aceita ficar sem rede quando o túnel não existe; o bloqueio é uma troca de disponibilidade e um interruptor ausente não justifica root.

O escopo é por perfil, não por aparelho: o Android permite um VPN ativo por perfil de usuário.

Um bloqueio no perfil de trabalho não diz nada sobre o lado pessoal, e testar um contexto não valida o outro.

Segunda decisão: bloquear tudo ou excluir algumas apps?

As exclusões por app no modo de bloqueio costumam ser entendidas ao contrário: segundo o Android apps excluídas podem perder a conexão em vez de usar em silêncio a rede comum, então excluir não é permissão para a internet.

Escolha conscientemente: bloqueie todo o tráfego coberto e aceite que as apps excluídas fiquem no escuro, ou desligue o bloqueio e aceite o caminho alternativo; se uma app precisa estar sempre conectada, o bloqueio é a ferramenta errada.

Terceira decisão: o que acontece antes do desbloqueio e em um portal?

Na maioria dos clientes o túnel não sobe até o usuário desbloquear o aparelho, então os primeiros instantes após o boot são uma lacuna, não uma falha; confirme isso para o cliente que você distribui.

Os portais cativos são a outra borda: uma rede de hotel ou aeroporto exige sessão de navegador sem autenticação e um bloqueio rígido pode tornar o login impossível; a resposta suportada é um fluxo de recuperação aprovado com gatilho, duração máxima, quem concede e a checagem de que a aplicação volta sozinha.

A documentação dos clientes VPN do Android cobre Always-On, bloqueio, exclusões por app e a regra de um VPN por perfil; leia antes de projetar de memória.

Teste o estado offline e depois escreva a linha de aceitação

Use tráfego inofensivo e o teste de falha suportado: conexão normal, perda do túnel, recuperação e reinício antes do desbloqueio, anotando se a app bloqueou como previsto.

Verifique o recurso e o resolver, não o ícone, e teste à parte um aparelho em tethering, porque a política do telefone não estabelece encaminhamento para clientes do ponto de acesso.

A linha de aceitação é concreta e testável: a app prevista no perfil previsto alcança o túnel aprovado e permanece no estado bloqueado exigido quando não consegue. Antes de assiná-la:

• Always-On e bloqueio estão configurados onde a plataforma os suporta e o dono de cada ajuste é conhecido.
• O escopo das apps é deliberado e você confirmou o que acontece com as apps excluídas no modo de bloqueio.
• A lacuna antes do desbloqueio e o fluxo do portal cativo estão decididos, não descobertos.
• O teste de falha foi feito na classe de aparelhos que você realmente distribui.