Berechtigung für das lokale Netzwerk

Auf Geräte in einem lokalen Netzwerk (LAN) kann von jeder App zugegriffen werden, die die Berechtigung INTERNET hat. Dadurch können Apps ganz einfach eine Verbindung zu lokalen Geräten herstellen. Es gibt aber auch datenschutzrechtliche Auswirkungen, z. B. die Erstellung eines Fingerabrucks des Nutzers und die Verwendung als Proxy für den Standort.

Das Projekt „Local Network Protections“ zielt darauf ab, die Privatsphäre des Nutzers zu schützen, indem der Zugriff auf das lokale Netzwerk durch eine neue Laufzeitberechtigung eingeschränkt wird.

Auswirkungen

In Android 16 ist diese Berechtigung eine optionale Funktion. Das bedeutet, dass nur Apps betroffen sind, die sich dafür entscheiden. Ziel ist es, dass App-Entwickler nachvollziehen können, welche Teile ihrer App auf impliziten Zugriff auf das lokale Netzwerk angewiesen sind, damit sie sich auf die Berechtigungsbeschränkung in einer zukünftigen Android-Version vorbereiten können.

Apps sind betroffen, wenn sie über eine der folgenden Methoden auf das lokale Netzwerk des Nutzers zugreifen:

• Direkte oder bibliotheksbasierte Verwendung von Raw Sockets für lokale Netzwerkadressen, z. B. Multicast DNS (mDNS) oder Simple Service Discovery Protocol (SSDP).
• Verwendung von Klassen auf Framework-Ebene, die auf das lokale Netzwerk zugreifen, z. B. NsdManager.

Details zu den Auswirkungen

Für Traffic zu und von einer lokalen Netzwerkadresse ist die Berechtigung für den Zugriff auf das lokale Netzwerk erforderlich. In der folgenden Tabelle sind einige häufige Fälle aufgeführt:

Diese Einschränkungen sind tief im Netzwerkstack implementiert und gelten daher für alle Netzwerk-APIs. Dazu gehören Sockets, die im Plattform- oder verwalteten Code erstellt wurden, Netzwerkbibliotheken wie Cronet und OkHttp sowie alle APIs, die darauf aufbauen. Wenn Sie versuchen, Dienste im lokalen Netzwerk aufzulösen, die das Suffix .local haben, ist die Berechtigung für das lokale Netzwerk erforderlich.

Ausnahmen von den oben genannten Regeln:

• Wenn sich der DNS-Server eines Geräts in einem lokalen Netzwerk befindet, ist für Traffic zu und von ihm (auf Port 53) keine Berechtigung für den Zugriff auf das lokale Netzwerk erforderlich.
• Für Anwendungen, die Output Switcher als In-App-Auswahl verwenden, sind keine Berechtigungen für das lokale Netzwerk erforderlich. Weitere Informationen folgen in einer späteren Version.

Erzwingung in Android 17

Ab Android 17 sind die Schutzmaßnahmen für das lokale Netzwerk obligatorisch und werden für Apps erzwungen, die auf Android 17 oder höher ausgerichtet sind.

Damit die App-Funktionalität nach der Erzwingung nicht beeinträchtigt wird, müssen Anwendungen, die auf SDK 37 oder höher ausgerichtet sind, eine der folgenden Methoden verwenden, um den Zugriff auf das lokale Netzwerk zu verwalten:

Methode A: Datenschutzfreundliche Auswahl verwenden

Verwenden Sie für von Systemen vermittelte Erkennungs- und Verbindungsaufgaben Auswahl, um die Anforderung der umfassenden Laufzeitberechtigung ganz zu vermeiden. Verwenden Sie je nach Anwendungsfall die folgenden Auswahl:

• Medienstreaming: Für Anwendungen, die Google Cast unterstützen, können Sie die Funktion „Ausgabe wechseln“ verwenden. So können Entwickler Nutzern die Möglichkeit geben, bestimmte Streaminggeräte auszuwählen, ohne dass die App die umfassende ACCESS_LOCAL_NETWORK Berechtigung anfordern muss.
• Allgemeine Konnektivität: Die NsdManager enthält eine vom System ausgeführte Dienstauswahl für die mDNS-Erkennung. Anstatt das gesamte Netzwerk zu scannen, zeigt das System ein Dialogfeld an, in dem der Nutzer ein einzelnes Gerät auswählen kann, auf das die App zugreifen soll.

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

Methode B: Laufzeitberechtigung anfordern (umfassender Zugriff)

Diese Methode ist für komplexe Anwendungsfälle wie die Heimautomatisierung oder die Verwaltung von IoT-Geräten erforderlich, die einen umfassenden, dauerhaften Zugriff auf das lokale Netzwerk benötigen.

• Berechtigung im Manifest deklarieren: Deklarieren Sie ACCESS_LOCAL_NETWORK explizit in der Datei AndroidManifest.xml.

• Berechtigung zur Laufzeit anfordern:Bevor Anwendungen versuchen, auf das lokale Netzwerk zuzugreifen, müssen sie prüfen, ob die Berechtigung erteilt wurde. Wenn nicht, müssen sie Activity.requestPermission() aufrufen, um die Standardaufforderung des Systems auszulösen.

• Szenario mit vorab erteilter Berechtigung:Die Berechtigung ACCESS_LOCAL_NETWORK ist Teil der Berechtigungsgruppe NEARBY_DEVICES. Wenn ein Nutzer bereits eine andere Berechtigung in dieser Gruppe erteilt hat (z. B. Bluetooth-Berechtigungen), wird er nicht noch einmal nach dem Zugriff auf das lokale Netzwerk gefragt.

• Ablehnung und Widerruf verarbeiten:Apps müssen Fälle angemessen verarbeiten, in denen der Nutzer die Anfrage ablehnt oder die Berechtigung später in den Systemeinstellungen widerruft. In solchen Fällen wird der Traffic im lokalen Netzwerk blockiert.

Strategie für den Zähler für das Zurücksetzen von Berechtigungsanfragen

Die Plattform implementiert eine Strategie zum Zurücksetzen des Zählers, die Szenarien berücksichtigt, in denen die vorherige Ablehnung der Berechtigungsgruppe NEARBY_DEVICES (die jetzt ACCESS_LOCAL_NETWORK umfasst) verhindert hat, dass die App nach einer angemessenen Begründung nach der Berechtigung gefragt hat. Dieser Mechanismus bietet der App zusätzliche Möglichkeiten, die requestPermission() API aufzurufen, wodurch der Zähler für die Ablehnung der ACCESS_LOCAL_NETWORK Berechtigung zurückgesetzt wird. So kann der Nutzer noch einmal angesprochen werden, insbesondere wenn die erste Ablehnung erfolgte, bevor die App die Notwendigkeit des Zugriffs auf das lokale Netzwerk für ihre Hauptfunktionen erläutern konnte.

Geteiltes Berechtigungsmodell

Die Berechtigung für das lokale Netzwerk verwendet eine Migrationsstrategie für geteilte Berechtigungen, um neue und ältere Anwendungen je nach Ziel-SDK unterschiedlich zu behandeln.

LNP-Strategie nach Anwendungsfall

• Streaming:Für Streamingfunktionen ist die am besten geeignete und datenschutzfreundlichste Strategie die Verwendung der Funktion „Ausgabe wechseln“. Mit dieser Methode kann das System die Erkennung und Verbindung im lokalen Netzwerk im Namen des Nutzers verarbeiten, sodass die App die Berechtigung ACCESS_LOCAL_NETWORK nicht anfordern muss.

• Browser:Die Fehlerbehandlung erfordert je nach Protokoll unterschiedliche Ansätze. UDP-Fehler führen zum Fehlercode EPERM. Bei TCP-Verbindungen sollten Browser die NDK-API android_getnetworkblockedreason(int sockFd) verwenden, um zu ermitteln, ob ein Paket von LNP blockiert wurde. Diese API gibt ANDROID_NETWORK_BLOCKED_REASON_LNP zurück.

• Andere Anwendungsfälle (z. B. IoT) : Anwendungen, die Geräte mit mDNS finden, sollten android.net.nsd.DiscoveryRequest#FLAG_SHOW_PICKER verwenden, um Geräte ohne Berechtigung zu finden, und NsdManager#registerServiceInfoCallback / NsdManager#resolveService, um IP-Adressen zu erhalten. Für Verbindungen zu IP-Adressen, die auf diese Weise abgerufen werden, ist die ACCESS_LOCAL_NETWORK Berechtigung nicht erforderlich.

Für Anwendungen, die eine direkte Kommunikation im lokalen Netzwerk erfordern und keine von Systemen vermittelten Auswahl verwenden können, empfiehlt sich die Strategie für den Zähler für das Zurücksetzen von Berechtigungen, wenn sie auf Android 17 (SDK 37) oder höher ausgerichtet sind. Wenn die ACCESS_LOCAL_NETWORK Berechtigung vom Nutzer widerrufen wird, bietet dieser Mechanismus der App zusätzliche Möglichkeiten, die Berechtigung noch einmal anzufordern, sodass Entwickler dem Nutzer eine klarere Begründung geben können.

Anleitung für Android 16

So aktivieren Sie die Einschränkungen für das lokale Netzwerk:

1. Flashen Sie Ihr Gerät mit einem Build mit Android 16 Beta 3 oder höher.
2. Installieren Sie die zu testende App.

3. Aktivieren oder deaktivieren Sie die Appcompat-Konfiguration mit adb.

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Starten Sie das Gerät neu.

Der Zugriff Ihrer App auf das lokale Netzwerk ist jetzt eingeschränkt und jeder Versuch, auf das lokale Netzwerk zuzugreifen, führt zu Socket-Fehlern. Wenn Sie APIs verwenden, die Vorgänge im lokalen Netzwerk außerhalb Ihres App-Prozesses ausführen (z. B. NsdManager), sind sie während der Aktivierung nicht betroffen.

Um den Zugriff wiederherzustellen, müssen Sie Ihrer App die Berechtigung für NEARBY_WIFI_DEVICES erteilen.

• Die App muss die Berechtigung NEARBY_WIFI_DEVICES in ihrem manifest deklarieren.
• Gehen Sie zu den Einstellungen > Apps > [App-Name] > Berechtigungen > Geräte in der Nähe > Zulassen.

Der Zugriff Ihrer App auf das lokale Netzwerk sollte jetzt wiederhergestellt sein und alle Ihre Szenarien sollten wie vor der Aktivierung der App funktionieren. So wirkt sich das auf den App-Netzwerktraffic aus.

Verwenden Sie den folgenden Befehl, um die Appcompat-Konfiguration zu deaktivieren:

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Fehler

Wenn eine Anfrage für den Zugriff auf das lokale Netzwerk aufgrund fehlender Berechtigungen fehlschlägt:

• Bei TCP-Verbindungen tritt in der Regel ein Zeitüberschreitungsfehler auf.

• UDP-Fehler und allgemeine Berechtigungsablehnungen führen in der Regel zum Fehlercode EPERM.

Fehler

Melden Sie Fehler und geben Sie Feedback zu folgenden Themen:

• Abweichungen beim LAN-Zugriff (Sie sind der Meinung, dass ein bestimmter Zugriff nicht als Zugriff auf das lokale Netzwerk betrachtet werden sollte)
• Fehler, bei denen der LAN-Zugriff blockiert werden sollte, aber nicht blockiert wird
• Fehler, bei denen der LAN-Zugriff nicht blockiert werden sollte, aber blockiert wird

Folgendes sollte von dieser Änderung nicht betroffen sein:

• Internetzugriff
• Mobilfunknetz