Permissão de rede local

Qualquer app com a permissão INTERNET pode acessar dispositivos em uma rede local (LAN). Isso facilita a conexão dos apps a dispositivos locais, mas também tem implicações de privacidade, como a formação de uma impressão digital do usuário e a atuação como um proxy de localização.

O projeto de proteções de rede local visa proteger a privacidade do usuário, restringindo o acesso à rede local com uma nova permissão de execução.

Impacto

No Android 16, essa permissão é um recurso opcional, o que significa que apenas os apps que a ativarem serão afetados. O objetivo da ativação é que os desenvolvedores de apps entendam quais partes do app dependem do acesso implícito à rede local para que possam se preparar para protegê-las com permissão em uma versão futura do Android.

Os apps serão afetados se acessarem a rede local do usuário usando:

• Uso direto ou de biblioteca de soquetes brutos em endereços de rede local, por exemplo, Multicast DNS (mDNS) ou Simple Service Discovery Protocol (SSDP).
• Uso de classes no nível do framework que acessam a rede local, por exemplo, NsdManager.

Detalhes do impacto

O tráfego de e para um endereço de rede local exige permissão de acesso à rede local. A tabela a seguir lista alguns casos comuns:

Essas restrições são implementadas na pilha de rede e, portanto, se aplicam a todas as APIs de rede. Isso inclui soquetes criados na plataforma ou no código gerenciado, bibliotecas de rede como Cronet e OkHttp e todas as APIs implementadas sobre elas. Tentar resolver serviços na rede local que tenham um sufixo .local exige permissão de rede local.

Exceções às regras anteriores:

• Se o servidor DNS de um dispositivo estiver em uma rede local, o tráfego de / para ele (na porta 53) não exigirá permissão de acesso à rede local.
• Os aplicativos que usam o Output Switcher como seletor no app não precisarão de permissões de rede local (mais orientações serão fornecidas em uma versão posterior).

Aplicação do Android 17

A partir do Android 17, as proteções de rede local são obrigatórias e aplicadas a apps direcionados ao Android 17 ou mais recente.

Para verificar se a funcionalidade do app não está quebrada após a aplicação, os aplicativos direcionados ao SDK 37 ou mais recente precisam adotar um dos caminhos a seguir para gerenciar o acesso à rede local:

Caminho A: usar seletores que preservam a privacidade

Para tarefas de descoberta e conexão mediadas pelo sistema, use seletores para evitar solicitar a permissão de execução ampla. Use os seletores a seguir com base no seu caso de uso:

• Transmissão de mídia: para aplicativos que oferecem suporte ao Google Cast, é possível usar o recurso de seletor de saída. Isso permite que os desenvolvedores permitam que os usuários selecionem dispositivos de transmissão específicos sem que o app precise solicitar a permissão ampla.ACCESS_LOCAL_NETWORK
• Conectividade geral: O NsdManager inclui um seletor de serviço executado pelo sistema para descoberta de mDNS. Em vez de o app verificar toda a rede, o sistema mostra uma caixa de diálogo que permite ao usuário selecionar um único dispositivo para o app acessar.

val discoveryRequest = DiscoveryRequest.Builder("_http._tcp")
    .setFlags(DiscoveryRequest.FLAG_SHOW_PICKER)
    .build()

nsdManager.registerServiceInfoCallback(discoveryRequest, executor, object : NsdManager.ServiceInfoCallback {
    override fun onServiceUpdated(serviceInfo: NsdServiceInfo) {
        // Handle the user-selected and discovered service
        // NsdServiceInfo.getHostAddresses() can now be connected to
        // without ACCESS_LOCAL_NETWORK permission
    }
})

Caminho B: solicitar permissão de execução (acesso amplo)

Esse caminho é necessário para casos de uso complexos, como automação residencial ou gerenciamento de dispositivos IoT que precisam de acesso amplo e persistente à rede local.

• Declarar permissão no manifesto: os desenvolvedores precisam declarar explicitamente ACCESS_LOCAL_NETWORK no AndroidManifest.xml.

• Solicitar permissão no momento da execução:antes de tentar qualquer acesso à rede local, os aplicativos precisam verificar se a permissão foi concedida. Caso contrário, eles precisam chamar Activity.requestPermission() para acionar o prompt padrão do sistema.

• Cenário pré-concedido: a permissão ACCESS_LOCAL_NETWORK faz parte do NEARBY_DEVICES grupo de permissões. Se um usuário já tiver concedido outra permissão nesse grupo (como permissões de Bluetooth), ele não receberá um novo prompt para acesso à rede local.

• Como lidar com a negação e a revogação:os apps precisam lidar normalmente com casos em que o usuário nega a solicitação ou revoga a permissão nas configurações do sistema. Nesses cenários, o tráfego de rede local será bloqueado.

Estratégia de contador de redefinição de solicitação de permissão

A plataforma implementa uma estratégia de redefinição de contador que aborda cenários em que a negação anterior do grupo de permissões NEARBY_DEVICES de um app (que agora inclui ACCESS_LOCAL_NETWORK) impediu que o app pedisse a permissão depois de apresentar adequadamente a justificativa. Esse mecanismo concede mais oportunidades para o app invocar a API requestPermission(), redefinindo efetivamente a contagem de negações da permissão ACCESS_LOCAL_NETWORK. Isso permite um novo engajamento mais sutil com o usuário, especialmente quando a negação inicial ocorreu antes que o app pudesse transmitir a necessidade de acesso à rede local para a funcionalidade principal.

Modelo de permissão dividida

A permissão de rede local usa uma estratégia de migração de permissão dividida para lidar com aplicativos novos e legados de maneira diferente, com base no SDK de destino.

Estratégia de LNP por caso de uso

• Transmissão: para funcionalidades de transmissão de mídia, a estratégia mais adequada e que preserva a privacidade é usar o seletor de saída. Esse método permite que o sistema processe a descoberta e a conexão de rede local em nome do usuário, eliminando a necessidade de o app solicitar a permissão ACCESS_LOCAL_NETWORK.

• Navegadores:o tratamento de erros exige abordagens diferentes com base no protocolo. Os erros de UDP resultam no código de erro EPERM. Para conexões TCP, os navegadores precisam usar a API NDK android_getnetworkblockedreason(int sockFd) para determinar se um pacote foi bloqueado pelo LNP. Essa API retorna ANDROID_NETWORK_BLOCKED_REASON_LNP.

• Outros casos de uso (por exemplo, IoT): os aplicativos que encontram dispositivos usando mDNS precisam usar android.net.nsd.DiscoveryRequest#FLAG_SHOW_PICKER que permite encontrar dispositivos sem a permissão, e NsdManager#registerServiceInfoCallback / NsdManager#resolveService para receber endereços IP. As conexões com endereços IP recebidos dessa forma não exigem a ACCESS_LOCAL_NETWORK permissão.

Para aplicativos que exigem comunicação direta de rede local e não podem usar seletores mediados pelo sistema, a abordagem sugerida é usar a estratégia de contador de redefinição de permissão. Se a permissão ACCESS_LOCAL_NETWORK for revogada por o usuário, esse mecanismo vai oferecer mais oportunidades para o app solicitar a permissão novamente, permitindo que os desenvolvedores apresentem uma justificativa mais clara para o usuário.

Orientação do Android 16

Para ativar as restrições de rede local, faça o seguinte:

1. Atualize o dispositivo para uma versão com o Android 16 Beta 3 ou mais recente.
2. Instale o app a ser testado.

3. Alterne a configuração do Appcompat usando adb.

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reinicialize o dispositivo.

Agora, o acesso do app à rede local está restrito, e qualquer tentativa de acesso à rede local leva a erros de soquete. Se você estiver usando APIs que executam operações de rede local fora do processo do app (por exemplo, NsdManager), elas não serão afetadas durante a ativação.

Para restaurar o acesso, conceda ao app a permissão NEARBY_WIFI_DEVICES.

• Verifique se o app declara a permissão NEARBY_WIFI_DEVICES no manifest.
• Acesse Configurações > Apps > [Nome do app] > Permissões > Dispositivos por perto > Permitir.

Agora, o acesso do app à rede local será restaurado, e todos os cenários funcionarão como antes da ativação do app. Veja como o tráfego de rede do app é afetado.

Use o comando a seguir para desativar a configuração do Appcompat

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Erros

Se uma solicitação de acesso à rede local falhar devido à permissão ausente:

• As conexões TCP geralmente resultam em um erro de tempo limite.

• Erros de UDP e negações de permissão gerais geralmente resultam em um código de erro EPERM.

Bugs

Envie bugs e feedback para:

• Discrepâncias no acesso à LAN (você não acha que um determinado acesso deva ser considerado acesso à "rede local")
• Bugs em que o acesso à LAN deveria ser bloqueado, mas não é
• Bugs em que o acesso à LAN não deveria ser bloqueado, mas é

O seguinte não será afetado por essa mudança:

• Acesso à Internet
• Rede móvel