Permissão de rede local

Os dispositivos em uma rede local (LAN) podem ser acessados por qualquer app que tenha a permissão INTERNET. Isso facilita a conexão dos apps com dispositivos locais, mas também tem implicações de privacidade, como a formação de uma impressão digital do usuário e o uso como proxy de localização.

O projeto Local Network Protections visa proteger a privacidade do usuário restringindo o acesso à rede local com uma nova permissão de tempo de execução.

Impacto

No Android 16, essa permissão é um recurso de ativação. Isso significa que apenas os apps que ativarem a opção 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 proteger as permissões 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 sockets brutos em endereços de rede local, por exemplo, Multicast DNS (mDNS) ou Simple Service Discovery Protocol (SSDP).
• Uso de classes no nível da estrutura 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 sockets criados na plataforma ou em 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 têm um sufixo .local requer 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 seletor de saída como seletor no app não vão precisar de permissões de rede local. Mais orientações serão fornecidas em uma versão futura.

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 foi afetada após a aplicação, os aplicativos destinados ao SDK 37 ou mais recente precisam adotar um dos seguintes caminhos 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 seguintes seletores com base no seu caso de uso:

• Streaming de mídia:os aplicativos compatíveis com o Google Cast podem usar o recurso seletor de saída. Isso permite que os desenvolvedores deixem os usuários selecionarem dispositivos de streaming específicos sem que o app precise solicitar a permissão ACCESS_LOCAL_NETWORK.
• Conectividade geral:o NsdManager inclui um seletor de serviços executado pelo sistema para descoberta de mDNS. Em vez de o app verificar toda a rede, o sistema mostra uma caixa de diálogo para que o usuário selecione 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.

• Declare a permissão no manifesto:declare explicitamente ACCESS_LOCAL_NETWORK no AndroidManifest.xml.

• Solicitar permissão no tempo de 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 comando padrão do sistema.

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

• Como lidar com a negação e a revogação:os apps precisam lidar com normalidade nos casos em que o usuário nega a solicitação ou revoga a permissão nas configurações do sistema. Nesses casos, 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 de um app ao grupo de permissões NEARBY_DEVICES (que agora inclui ACCESS_LOCAL_NETWORK) impediu que ele pedisse a permissão depois de apresentar adequadamente a justificativa. Esse mecanismo concede mais oportunidades para o app invocar a API requestPermission(), redefinindo a contagem de negações para a permissão ACCESS_LOCAL_NETWORK. Isso permite um reengajamento mais sutil com o usuário, especialmente quando a recusa inicial ocorreu antes que o app pudesse transmitir a necessidade de acesso à rede local para sua 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 processar aplicativos novos e legados de maneira diferente, com base no SDK de destino.

Estratégia de PNL 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): 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 obtidos dessa forma não exigem a permissão ACCESS_LOCAL_NETWORK.

Para aplicativos que exigem comunicação direta com a 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 pelo 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 sobre o Android 16

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

1. Atualizar o dispositivo para um build com o Android 16 Beta 3 ou mais recente
2. Instalar o app a ser testado

3. Ativar ou desativar a configuração do Appcompat usando o adb

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reinicie o dispositivo.

Agora, o acesso do app à rede local está restrito, e qualquer tentativa de acessar a rede local resulta em erros de soquete. Se você estiver usando APIs que realizam 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 permissão para 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 deve ser restaurado, e todos os seus cenários vão funcionar como antes de ativar o 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 à ausência de permissão:

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

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

Bugs

Envie bugs e feedback sobre:

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

Os seguintes itens não serão afetados por essa mudança:

• Acesso à Internet
• Rede móvel