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. Das hat aber auch Auswirkungen auf den Datenschutz, z. B. in Bezug auf die Erstellung eines Fingerabdrucks 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.

Positiv beeinflussen

Unter Android 16 ist diese Berechtigung eine Opt-in-Funktion. Das bedeutet, dass nur die Apps betroffen sind, die sich für diese Funktion anmelden. Das Ziel der Einwilligungserklärung ist, dass App-Entwickler nachvollziehen können, welche Teile ihrer App von einem impliziten Zugriff auf das lokale Netzwerk abhängen, damit sie sich darauf vorbereiten können, diese in einem zukünftigen Android-Release durch Berechtigungen zu schützen.

Apps sind betroffen, wenn sie über folgende 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 Netzwerk-Stack implementiert und gelten daher für alle Netzwerk-APIs. Dazu gehören Sockets, die in der Plattform oder im verwalteten Code erstellt wurden, Netzwerkbibliotheken wie Cronet und OkHttp sowie alle APIs, die darauf basieren. Das Auflösen von Diensten im lokalen Netzwerk, die das Suffix .local haben, erfordert die Berechtigung für das lokale Netzwerk.

Ausnahmen von den vorhergehenden Regeln:

• Wenn sich der DNS-Server eines Geräts in einem lokalen Netzwerk befindet, ist für den Traffic zu / von ihm (über 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.

Durchsetzung von Android 17

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

Damit die App-Funktionalität nach der Durchsetzung nicht beeinträchtigt wird, müssen Apps, die auf SDK 37 oder höher ausgerichtet sind, einen der folgenden Ansätze für den Zugriff auf das lokale Netzwerk verwenden:

Pfad A: Datenschutzfreundliche Auswahltools verwenden

Verwenden Sie für systemvermittelte Erkennungs- und Verbindungsaufgaben Auswahlfelder, um die umfassende Laufzeitberechtigung nicht anfordern zu müssen. Verwenden Sie je nach Anwendungsfall die folgenden Auswahlfelder:

• Media-Streaming:Anwendungen, die Google Cast unterstützen, können die Ausgabeauswahl verwenden. So können Entwickler Nutzern ermöglichen, bestimmte Streaminggeräte auszuwählen, ohne dass die App die umfassende Berechtigung ACCESS_LOCAL_NETWORK anfordern muss.
• Allgemeine Konnektivität:Das 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 für den Zugriff durch die App auswählen kann.

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

Pfad B: Laufzeitberechtigung anfordern (breiter Zugriff)

Dieser Pfad ist für komplexe Anwendungsfälle wie die Smart-Home-Automatisierung oder die Verwaltung von IoT-Geräten erforderlich, die einen umfassenden, dauerhaften Zugriff auf das lokale Netzwerk benötigen.

• Berechtigung im Manifest deklarieren:Entwickler müssen ACCESS_LOCAL_NETWORK explizit im AndroidManifest.xml deklarieren.

• Berechtigung zur Laufzeit anfordern:Bevor eine App versucht, auf das lokale Netzwerk zuzugreifen, muss sie prüfen, ob die Berechtigung erteilt wurde. Andernfalls müssen sie Activity.requestPermission() aufrufen, um den Standard-Systemprompt 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 gewährt hat, z. B. Bluetooth-Berechtigungen, wird er nicht noch einmal zum lokalen Netzwerkzugriff aufgefordert.

• Ablehnung und Widerruf von Berechtigungen:Apps müssen angemessen auf Fälle reagieren, in denen der Nutzer die Anfrage ablehnt oder die Berechtigung später in den Systemeinstellungen widerruft. In solchen Fällen wird der lokale Netzwerkverkehr blockiert.

Strategie zum Zurücksetzen des Zählers für Berechtigungsanfragen

Die Plattform implementiert eine Strategie zum Zurücksetzen von Zählern, die Szenarien berücksichtigt, in denen die vorherige Ablehnung der Berechtigungsgruppe NEARBY_DEVICES (die jetzt ACCESS_LOCAL_NETWORK enthält) durch eine App verhindert hat, dass die App nach angemessener Darstellung der Begründung die Berechtigung anfordern konnte. Dieser Mechanismus bietet der App zusätzliche Möglichkeiten, die requestPermission() API aufzurufen, wodurch die Anzahl der Ablehnungen für die Berechtigung ACCESS_LOCAL_NETWORK zurückgesetzt wird. So kann der Nutzer noch einmal auf differenziertere Weise angesprochen werden, insbesondere wenn die ursprüngliche Ablehnung erfolgte, bevor die App die Notwendigkeit des lokalen Netzwerkzugriffs für ihre Hauptfunktionen erläutern konnte.

Aufgeteiltes Berechtigungsmodell

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

LNP-Strategie nach Anwendungsfall

• Casting:Für Media-Casting-Funktionen ist die Verwendung des Ausgabewählers die am besten geeignete und datenschutzfreundlichste Strategie. Bei dieser Methode kann das System die Erkennung und Verbindung mit dem lokalen Netzwerk im Namen des Nutzers übernehmen. Die App muss also nicht die Berechtigung ACCESS_LOCAL_NETWORK anfordern.

• 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 festzustellen, 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 über 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 abzurufen. Für Verbindungen zu IP-Adressen, die auf diese Weise abgerufen werden, ist die Berechtigung ACCESS_LOCAL_NETWORK nicht erforderlich.

Für Anwendungen, die eine direkte lokale Netzwerkkommunikation erfordern und keine vom System vermittelten Auswahlmöglichkeiten verwenden können, wird empfohlen, die Strategie für das Zurücksetzen von Berechtigungen zu verwenden. Wenn die Berechtigung ACCESS_LOCAL_NETWORK vom Nutzer widerrufen wird, bietet dieser Mechanismus zusätzliche Möglichkeiten für die App, die Berechtigung noch einmal anzufordern. So können Entwickler dem Nutzer eine klarere Begründung präsentieren.

Android 16-Leitfaden

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

1. Flashen Sie auf Ihrem Gerät einen Build mit Android 16 Beta 3 oder höher.
2. Zu testende App installieren

3. AppCompat-Konfiguration mit ADB umschalten

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Gerät neu starten

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 lokale Netzwerkoperationen außerhalb des App-Prozesses ausführen (z. B. NsdManager), sind diese während der Einwilligung 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 ihrer manifest deklarieren.
• Gehen Sie zu 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 ein lokales Netzwerk aufgrund fehlender Berechtigungen fehlschlägt:

• TCP-Verbindungen führen in der Regel zu einem Zeitüberschreitungsfehler.

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

Fehler

Fehler und Feedback einreichen für:

• 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, es aber nicht wird
• Fehler, bei denen der LAN-Zugriff blockiert wird, obwohl er nicht blockiert werden sollte

Folgendes sollte von dieser Änderung nicht betroffen sein:

• Internetzugang
• Mobilfunknetz