Autorizzazione di accesso alla rete locale

Le app con l'autorizzazione INTERNET possono accedere ai dispositivi su una rete locale (LAN). In questo modo, le app possono connettersi facilmente ai dispositivi locali, ma ciò comporta anche implicazioni per la privacy, ad esempio la creazione di un'impronta digitale dell'utente e l'utilizzo di un proxy per la località.

Il progetto Protezioni della rete locale mira a proteggere la privacy dell'utente tramite limitando l'accesso alla rete locale tramite una nuova autorizzazione di runtime.

Impatto

Durante Android 16, questa autorizzazione è una funzionalità di attivazione, il che significa che solo le app che la attivano saranno interessate. L'obiettivo dell'attivazione è consentire agli sviluppatori di app di comprendere quali parti della loro app dipendono dall'accesso implicito alla rete locale, in modo che possano prepararsi a proteggerle con le autorizzazioni in una release futura di Android.

Le app saranno interessate se accedono alla rete locale dell'utente utilizzando:

• L'utilizzo diretto o tramite libreria di socket non elaborati sugli indirizzi della rete locale, ad esempio Multicast DNS (mDNS) o Simple Service Discovery Protocol (SSDP).
• L'utilizzo di classi a livello di framework che accedono alla rete locale, ad esempio NsdManager.

Dettagli sull'impatto

Il traffico verso e da un indirizzo di rete locale richiede l'autorizzazione di accesso alla rete locale La tabella seguente elenca alcuni casi comuni:

Queste limitazioni sono implementate in profondità nello stack di rete e pertanto si applicano a tutte le API di rete. Sono inclusi i socket creati nel codice della piattaforma o gestito, le librerie di rete come Cronet e OkHttp e tutte le API implementate su di esse. Il tentativo di risolvere i servizi sulla rete locale con il suffisso .local richiede l'autorizzazione di rete locale.

Eccezioni alle regole precedenti:

• Se il server DNS di un dispositivo si trova su una rete locale, il traffico verso / da questo server (sulla porta 53) non richiede l'autorizzazione di accesso alla rete locale.
• Le applicazioni che utilizzano Output Switcher come selettore in-app non avranno bisogno delle autorizzazioni di rete locale (ulteriori indicazioni verranno fornite in una release successiva).

Applicazione di Android 17

A partire da Android 17, le protezioni della rete locale sono obbligatorie e vengono applicate alle app che hanno come target Android 17 o versioni successive.

Per verificare che la funzionalità dell'app non sia interrotta dopo l'applicazione, le applicazioni che hanno come target l'SDK 37 o versioni successive devono adottare uno dei seguenti percorsi per gestire l'accesso alla rete locale:

Percorso A: utilizzo di selettori che tutelano la privacy

Per le attività di rilevamento e connessione mediate dal sistema, utilizza i selettori per evitare di richiedere completamente l'autorizzazione di runtime generale. Utilizza i seguenti selettori in base al tuo caso d'uso:

• Streaming di contenuti multimediali: le applicazioni che supportano Google Cast possono utilizzare la funzionalità di cambio di output. In questo modo, gli sviluppatori possono consentire agli utenti di selezionare dispositivi di streaming specifici senza che l'app debba richiedere l'autorizzazione generale ACCESS_LOCAL_NETWORK
• Connettività generale: NsdManager include un selettore di servizi gestito dal sistema per il rilevamento mDNS. Anziché eseguire la scansione dell'intera rete, il sistema visualizza una finestra di dialogo che consente all'utente di selezionare un singolo dispositivo a cui l'app può accedere.

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
    }
})

Percorso B: richiesta dell'autorizzazione di runtime (accesso generale)

Questo percorso è necessario per casi d'uso complessi come la domotica o la gestione dei dispositivi IoT che richiedono un accesso generale e persistente alla rete locale.

• Dichiarazione dell'autorizzazione nel file manifest: gli sviluppatori devono dichiarare esplicitamente ACCESS_LOCAL_NETWORK nel AndroidManifest.xml.

• Richiesta dell'autorizzazione in fase di runtime: prima di tentare qualsiasi accesso alla rete locale, le applicazioni devono verificare se l'autorizzazione è stata concessa. In caso contrario, devono chiamare Activity.requestPermission() per attivare il prompt di sistema standard.

• Scenario di autorizzazione preliminare: L'autorizzazione ACCESS_LOCAL_NETWORK fa parte del gruppo di autorizzazioni NEARBY_DEVICES. Se un utente ha già concesso un'altra autorizzazione in questo gruppo (ad esempio le autorizzazioni Bluetooth), non gli verrà richiesto di nuovo l'accesso alla rete locale.

• Gestione del rifiuto e della revoca: le app devono gestire correttamente i casi in cui l'utente rifiuta la richiesta o revoca in un secondo momento l'autorizzazione nelle impostazioni di sistema. In questi scenari, il traffico di rete locale verrà bloccato.

Strategia del contatore di reimpostazione delle richieste di autorizzazione

La piattaforma implementa una strategia di reimpostazione del contatore che risolve gli scenari in cui il precedente rifiuto da parte di un'app del gruppo di autorizzazioni NEARBY_DEVICES (che ora include ACCESS_LOCAL_NETWORK) ha impedito all'app di richiedere l'autorizzazione dopo aver presentato adeguatamente la sua motivazione. Questo meccanismo offre all'app ulteriori opportunità di richiamare l'API requestPermission(), reimpostando di fatto il conteggio dei rifiuti per l'autorizzazione ACCESS_LOCAL_NETWORK. Ciò consente un coinvolgimento più sfumato dell'utente, soprattutto quando il rifiuto iniziale si è verificato prima che l'app potesse comunicare la necessità dell'accesso alla rete locale per la sua funzionalità di base.

Modello di autorizzazione suddivisa

L'autorizzazione di rete locale utilizza una strategia di migrazione delle autorizzazioni suddivise per gestire in modo diverso le applicazioni nuove e legacy, in base all'SDK target.

Strategia LNP per caso d'uso

• Trasmissione: per le funzionalità di trasmissione di contenuti multimediali, la strategia più appropriata e che tutela la privacy è l'utilizzo del cambio di output. Questo metodo consente al sistema di gestire il rilevamento e la connessione alla rete locale per conto dell'utente, eliminando la necessità che l'app richieda l'autorizzazione ACCESS_LOCAL_NETWORK.

• Browser: la gestione degli errori richiede approcci diversi in base al protocollo. Gli errori UDP generano il codice di errore EPERM. Per le connessioni TCP, i browser devono utilizzare l'API NDK android_getnetworkblockedreason(int sockFd) per determinare se un pacchetto è stato bloccato da LNP. Questa API restituisce ANDROID_NETWORK_BLOCKED_REASON_LNP.

• Altri casi d'uso (ad esempio IoT): le applicazioni che trovano i dispositivi utilizzando mDNS devono utilizzare android.net.nsd.DiscoveryRequest#FLAG_SHOW_PICKER che consente di trovare i dispositivi senza l'autorizzazione, e NsdManager#registerServiceInfoCallback / NsdManager#resolveService per ottenere gli indirizzi IP. Le connessioni agli indirizzi IP ottenuti in questo modo non richiedono l'autorizzazione ACCESS_LOCAL_NETWORK

Per le applicazioni che richiedono la comunicazione diretta con la rete locale e non possono utilizzare i selettori mediati dal sistema, l'approccio suggerito è quello di utilizzare la strategia del contatore di reimpostazione delle autorizzazioni. Se l'autorizzazione ACCESS_LOCAL_NETWORK viene revocata da l'utente, questo meccanismo offre all'app ulteriori opportunità di richiedere nuovamente l'autorizzazione, consentendo agli sviluppatori di presentare una motivazione più chiara all'utente.

Indicazioni per Android 16

Per attivare le limitazioni della rete locale:

1. Installa una build con Android 16 Beta 3 o versioni successive sul dispositivo
2. Installa l'app da testare

3. Attiva/disattiva la configurazione di Appcompat utilizzando adb

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Riavvia il dispositivo

Ora l'accesso dell'app alla rete locale è limitato e qualsiasi tentativo di accesso alla rete locale genera errori di socket. Se utilizzi API che eseguono operazioni di rete locale al di fuori del processo dell'app (ad esempio NsdManager), queste non sono interessate durante l'attivazione.

Per ripristinare l'accesso, devi concedere all'app l'autorizzazione NEARBY_WIFI_DEVICES.

• Assicurati che l'app dichiari l'autorizzazione NEARBY_WIFI_DEVICES nel relativo manifest.
• Vai a Impostazioni > App > [Nome app] > Autorizzazioni > Dispositivi nelle vicinanze > Consenti.

Ora l'accesso dell'app alla rete locale dovrebbe essere ripristinato e tutti gli scenari dovrebbero funzionare come prima dell'attivazione dell'app. Ecco l'impatto sul traffico di rete dell' app.

Utilizza il seguente comando per disattivare la configurazione di Appcompat

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errori

Se una richiesta di accesso alla rete locale non va a buon fine a causa dell'autorizzazione mancante:

• Le connessioni TCP in genere generano un errore di timeout.

• Gli errori UDP e i rifiuti generali delle autorizzazioni in genere generano un codice di errore EPERM.

Bug

Invia bug e feedback per:

• Discrepanze nell'accesso LAN (non ritieni che un determinato accesso debba essere considerato accesso alla "rete locale")
• Bug in cui l'accesso LAN dovrebbe essere bloccato, ma non lo è
• Bug in cui l'accesso LAN non dovrebbe essere bloccato, ma lo è

I seguenti elementi non dovrebbero essere interessati da questa modifica:

• Accesso a internet
• Rete mobile