Netzwerkstatus lesen

Unter Android können Apps dynamische Änderungen bei der Verbindung erkennen. Verwenden Sie die folgenden Klassen, um Konnektivitätsänderungen zu erfassen und darauf zu reagieren:

• ConnectivityManager informiert Ihre App über den Verbindungsstatus im System.
• Die Klasse Network stellt eines der Netzwerke dar, mit denen das Gerät verbunden ist. Sie können das Network-Objekt als Schlüssel verwenden, um mit ConnectivityManager Informationen zum Netzwerk zu erfassen oder Sockets im Netzwerk zu binden. Wenn die Netzwerkverbindung getrennt wird, kann das Network-Objekt nicht mehr verwendet werden. Auch wenn das Gerät später wieder mit demselben Gerät verbunden wird, stellt ein neues Network-Objekt das neue Netzwerk dar.
• Das LinkProperties-Objekt enthält Informationen zum Link für ein Netzwerk, z. B. die Liste der DNS-Server, lokalen IP-Adressen und Netzwerkrouten, die für das Netzwerk installiert sind.
• Das Objekt NetworkCapabilities enthält Informationen zu Eigenschaften eines Netzwerks, z. B. zu den Transportmethoden (WLAN, Mobilfunk, Bluetooth) und den Funktionen des Netzwerks. Sie können das Objekt beispielsweise abfragen, um festzustellen, ob das Netzwerk MMS senden kann, sich hinter einem Captive Portal befindet oder ob die Nutzung des Netzwerks kostenpflichtig ist.

Apps, die sich für den unmittelbaren Verbindungsstatus zu einem bestimmten Zeitpunkt interessieren, können ConnectivityManager-Methoden aufrufen, um herauszufinden, welche Art von Netzwerk verfügbar ist. Diese Methoden sind hilfreich zum Debuggen und um gelegentlich einen Snapshot der Konnektivität zu einem bestimmten Zeitpunkt zu überprüfen.

Die synchronen ConnectivityManager-Methoden informieren Ihre App jedoch nicht über Ereignisse, die nach einem Aufruf eintreten. Daher können Sie die Benutzeroberfläche nicht aktualisieren. Außerdem können sie das App-Verhalten nicht anpassen, wenn die Netzwerkverbindung unterbrochen wird oder sich die Netzwerkfunktionen ändern.

Die Konnektivität kann sich jederzeit ändern. Die meisten Apps benötigen daher eine stets aktuelle Ansicht des Netzwerkstatus auf dem Gerät. Apps können mit ConnectivityManager einen Callback registrieren, um über Änderungen informiert zu werden, die für die App relevant sind. Mithilfe des Rückrufs kann Ihre App sofort auf relevante Änderungen der Verbindung reagieren, ohne auf teures Polling zurückgreifen zu müssen, bei dem schnelle Updates möglicherweise nicht erfasst werden.

Für die Verwendung von NetworkCallback und anderen Methoden zum Ermitteln des Verbindungsstatus des Geräts sind keine besonderen Berechtigungen erforderlich. Für einige Netzwerke gelten jedoch bestimmte Berechtigungen. So gibt es möglicherweise eingeschränkte Netzwerke, auf die Apps nicht zugreifen können. Für die Bindung an ein Hintergrundnetzwerk ist die Berechtigung CHANGE_NETWORK_STATE erforderlich. Für einige Aufrufe sind möglicherweise bestimmte Berechtigungen erforderlich. Weitere Informationen finden Sie in der Dokumentation zu den einzelnen Aufrufen.

Momentanen Status abrufen

Ein Android-Gerät kann gleichzeitig viele Verbindungen aufrechterhalten. Wenn Sie Informationen zum aktuellen Netzwerkstatus abrufen möchten, müssen Sie zuerst eine Instanz von ConnectivityManager abrufen:

val connectivityManager = getSystemService(ConnectivityManager::class.java)

ConnectivityManager connectivityManager = getSystemService(ConnectivityManager.class);

Verwenden Sie diese Instanz als Nächstes, um einen Verweis auf das aktuelle Standardnetzwerk für Ihre App zu erhalten:

val currentNetwork = connectivityManager.getActiveNetwork()

Network currentNetwork = connectivityManager.getActiveNetwork();

Mit einem Verweis auf ein Netzwerk kann Ihre App Informationen dazu anfordern:

val caps = connectivityManager.getNetworkCapabilities(currentNetwork)
val linkProperties = connectivityManager.getLinkProperties(currentNetwork)

NetworkCapabilities caps = connectivityManager.getNetworkCapabilities(currentNetwork);
LinkProperties linkProperties = connectivityManager.getLinkProperties(currentNetwork);

Wenn Sie weitere nützliche Funktionen nutzen möchten, registrieren Sie ein NetworkCallback. Weitere Informationen zum Registrieren von Netzwerk-Callbacks finden Sie unter Netzwerkereignisse abhören.

NetworkCapabilities und LinkProperties

Die Objekte NetworkCapabilities und LinkProperties enthalten Informationen zu allen Attributen, die das System zu einem Netzwerk kennt.

Das LinkProperties-Objekt kennt die Routen, Linkadressen, den Schnittstellennamen, Proxyinformationen (falls vorhanden) und DNS-Server. Rufen Sie die entsprechende Methode für das LinkProperties-Objekt auf, um die benötigten Informationen abzurufen.

Das NetworkCapabilities-Objekt enthält Informationen zu den Netzwerktransporten und ihren Funktionen.

Ein Transport ist eine Abstraktion eines physischen Mediums, über das ein Netzwerk funktioniert. Häufige Beispiele für Transportmittel sind Ethernet, WLAN und Mobilfunk. VPNs und Peer-to-Peer-WLAN können ebenfalls als Transportmittel dienen. Auf Android-Geräten kann ein Netzwerk gleichzeitig mehrere Transportmittel haben. Ein Beispiel hierfür ist ein VPN, das sowohl über WLAN als auch über Mobilfunknetze funktioniert. Das VPN hat die Transportprotokolle WLAN, Mobilfunk und VPN. Wenn Sie herausfinden möchten, ob ein Netzwerk einen bestimmten Transport hat, verwenden Sie die Methode NetworkCapabilities.hasTransport(int) mit einer der NetworkCapabilities.TRANSPORT_*-Konstanten.

Eine Funktion beschreibt eine Eigenschaft des Netzwerks. Beispiele für Funktionen sind MMS, NOT_METERED und INTERNET. In einem Netzwerk mit MMS-Funktion können MMS-Nachrichten gesendet und empfangen werden. In einem Netzwerk ohne diese Funktion ist das nicht möglich. In einem Netzwerk mit der Funktion NOT_METERED wird dem Nutzer keine Datenübertragung in Rechnung gestellt. Ihre App kann mit der Methode NetworkCapabilities.hasCapability(int) und einer der NetworkCapabilities.NET_CAPABILITY_*-Konstanten nach geeigneten Funktionen suchen.

Die nützlichsten NET_CAPABILITY_*-Konstanten sind:

• NET_CAPABILITY_INTERNET: Gibt an, dass das Netzwerk für den Internetzugriff eingerichtet ist. Es geht hier um die Einrichtung und nicht um die tatsächliche Fähigkeit, öffentliche Server zu erreichen. So kann beispielsweise ein Netzwerk eingerichtet werden, das den Internetzugriff ermöglicht, aber einem Captive Portal unterliegt.

  Das Mobilfunknetz eines Mobilfunkanbieters hat in der Regel die INTERNET-Funktion, ein lokales P2P-WLAN-Netzwerk in der Regel nicht. Informationen zur tatsächlichen Konnektivität finden Sie unter NET_CAPABILITY_VALIDATED.

• NET_CAPABILITY_NOT_METERED: Gibt an, dass das Netzwerk nicht getaktet ist. Ein Netzwerk wird als getaktet eingestuft, wenn der Nutzer aufgrund von Kosten, Datenbeschränkungen oder Problemen mit der Akkuleistung empfindlich auf eine hohe Datennutzung über diese Verbindung reagiert.

• NET_CAPABILITY_NOT_VPN: Gibt an, dass das Netzwerk kein virtuelles privates Netzwerk ist.

• NET_CAPABILITY_VALIDATED: Gibt an, dass das Netzwerk bei einer Anfrage tatsächlichen Zugriff auf das öffentliche Internet bietet. Ein Netzwerk hinter einem Captive Portal oder ein Netzwerk, das keine Auflösung von Domainnamen bietet, hat diese Funktion nicht. Das ist die genaueste Aussage, die das System über ein Netzwerk machen kann, das tatsächlich Zugriff bietet. Ein bestätigtes Netzwerk kann jedoch grundsätzlich IP-basierten Filtern unterliegen oder aufgrund von Problemen wie einem schlechten Signal plötzlich die Verbindung verlieren.

• NET_CAPABILITY_CAPTIVE_PORTAL: Gibt an, dass das Netzwerk bei der Überprüfung ein Captive Portal hat.

Es gibt weitere Funktionen, die für spezialisierte Apps interessant sein könnten. Weitere Informationen finden Sie in den Parameterdefinitionen unter NetworkCapabilities.hasCapability(int).

Die Funktionen eines Netzwerks können sich jederzeit ändern. Wenn das System ein Captive Portal erkennt, wird eine Benachrichtigung angezeigt, in der der Nutzer aufgefordert wird, sich anzumelden. Während dieser Zeit verfügt das Netzwerk über die Funktionen NET_CAPABILITY_INTERNET und NET_CAPABILITY_CAPTIVE_PORTAL, aber nicht über die Funktion NET_CAPABILITY_VALIDATED.

Wenn der Nutzer Maßnahmen ergreift und sich auf der Captive Portal-Seite anmeldet, kann das Gerät auf das öffentliche Internet zugreifen. Das Netzwerk erhält die NET_CAPABILITY_VALIDATED-Funktion und verliert die NET_CAPABILITY_CAPTIVE_PORTAL-Funktion.

Auch die Transporte eines Netzwerks können sich dynamisch ändern. Ein VPN kann sich beispielsweise so konfigurieren, dass es ein schnelleres Netzwerk verwendet, das gerade verfügbar geworden ist, z. B. durch Wechsel vom Mobilfunknetz zum WLAN. In diesem Fall verliert das Netzwerk den TRANSPORT_CELLULAR-Transport und erhält den TRANSPORT_WIFI-Transport, während der TRANSPORT_VPN-Transport beibehalten wird.

Auf Netzwerkereignisse warten

Informationen zu Netzwerkereignissen erhalten Sie mit der Klasse NetworkCallback in Kombination mit ConnectivityManager.registerDefaultNetworkCallback(NetworkCallback) und ConnectivityManager.registerNetworkCallback(NetworkCallback). Diese beiden Methoden dienen unterschiedlichen Zwecken.

Alle Android-Apps haben ein Standardnetzwerk, das vom System festgelegt wird. Das System bevorzugt in der Regel Netzwerke mit unbegrenztem Datenvolumen gegenüber Netzwerken mit begrenztem Datenvolumen und schnellere Netzwerke gegenüber langsameren.

Wenn eine App eine Netzwerkanfrage stellt, z. B. mit HttpsURLConnection, wird diese Anfrage vom System über das Standardnetzwerk ausgeführt. Apps können auch Traffic über andere Netzwerke senden. Weitere Informationen finden Sie im Abschnitt zu zusätzlichen Netzwerken.

Das als Standardnetzwerk festgelegte Netzwerk kann sich jederzeit ändern. Ein typisches Beispiel ist, wenn das Gerät in Reichweite eines bekannten, aktiven, nicht getakteten und schnelleren WLAN-Zugangspunkts kommt. Das Gerät stellt eine Verbindung zu diesem Zugangspunkt her und ändert das Standardnetzwerk für alle Apps in das neue WLAN.

Wenn ein neues Netzwerk zum Standardnetzwerk wird, verwendet jede neue Verbindung, die die App öffnet, dieses Netzwerk. Irgendwann später werden alle verbleibenden Verbindungen im vorherigen Standardnetzwerk zwangsweise beendet. Wenn es für die App wichtig ist, zu wissen, wann sich das Standardnetzwerk ändert, registriert sie einen Standardnetzwerk-Callback so:

connectivityManager.registerDefaultNetworkCallback(object : ConnectivityManager.NetworkCallback() {
    override fun onAvailable(network : Network) {
        Log.e(TAG, "The default network is now: " + network)
    }

    override fun onLost(network : Network) {
        Log.e(TAG, "The application no longer has a default network. The last default network was " + network)
    }

    override fun onCapabilitiesChanged(network : Network, networkCapabilities : NetworkCapabilities) {
        Log.e(TAG, "The default network changed capabilities: " + networkCapabilities)
    }

    override fun onLinkPropertiesChanged(network : Network, linkProperties : LinkProperties) {
        Log.e(TAG, "The default network changed link properties: " + linkProperties)
    }
})

connectivityManager.registerDefaultNetworkCallback(new ConnectivityManager.NetworkCallback() {
    @Override
    public void onAvailable(Network network) {
        Log.e(TAG, "The default network is now: " + network);
    }

    @Override
    public void onLost(Network network) {
        Log.e(TAG, "The application no longer has a default network. The last default network was " + network);
    }

    @Override
    public void onCapabilitiesChanged(Network network, NetworkCapabilities networkCapabilities) {
        Log.e(TAG, "The default network changed capabilities: " + networkCapabilities);
    }

    @Override
    public void onLinkPropertiesChanged(Network network, LinkProperties linkProperties) {
        Log.e(TAG, "The default network changed link properties: " + linkProperties);
    }
});

Wenn ein neues Netzwerk zum Standardnetzwerk wird, erhält die App einen Aufruf von onAvailable(Network) für das neue Netzwerk. Implementieren Sie onCapabilitiesChanged(Network,NetworkCapabilities), onLinkPropertiesChanged(Network,LinkProperties) oder beides, um angemessen auf Änderungen der Verbindung zu reagieren.

Bei einem mit registerDefaultNetworkCallback() registrierten Callback bedeutet onLost(), dass das Netzwerk nicht mehr das Standardnetzwerk ist. Möglicherweise ist die Verbindung getrennt.

Sie können zwar die Transportprotokolle des Standardnetzwerks abfragen, indem Sie NetworkCapabilities.hasTransport(int) aufrufen, aber das ist kein guter Proxy für die Bandbreite oder die Abrechnung des Netzwerks. Ihre App kann nicht davon ausgehen, dass WLAN immer unbegrenzt ist und immer eine bessere Bandbreite als Mobilfunk bietet.

Verwenden Sie stattdessen NetworkCapabilities.getLinkDownstreamBandwidthKbps(), um die Bandbreite zu messen, und NetworkCapabilites.hasCapability(int) mit NET_CAPABILITY_NOT_METERED-Argumenten, um die Abrechnung zu bestimmen. Weitere Informationen finden Sie im Abschnitt NetworkCapabilities und LinkProperties.

Standardmäßig werden die Callback-Methoden im Connectivity-Thread Ihrer App aufgerufen. Das ist ein separater Thread, der von ConnectivityManager verwendet wird. Wenn in Ihrer Implementierung der Callbacks längere Vorgänge ausgeführt werden müssen, rufen Sie sie in einem separaten Worker-Thread mit der Variante ConnectivityManager.registerDefaultNetworkCallback(NetworkCallback, Handler) auf.

Heben Sie die Registrierung Ihres Callbacks auf, wenn Sie ihn nicht mehr benötigen, indem Sie ConnectivityManager.unregisterNetworkCallback(NetworkCallback) aufrufen. Die onPause() Ihrer Hauptaktivität ist ein guter Ort dafür, insbesondere wenn Sie den Callback in onResume() registrieren.

Zusätzliche Netzwerke (komplexere Anwendungsfälle)

Das Standardnetzwerk ist zwar für die meisten Apps das einzige relevante Netzwerk, aber einige Apps sind möglicherweise an anderen verfügbaren Netzwerken interessiert. Um diese Informationen zu erhalten, erstellen Apps ein NetworkRequest, das ihren Anforderungen entspricht, und rufen ConnectivityManager.registerNetworkCallback(NetworkRequest, NetworkCallback) auf.

Der Vorgang ähnelt dem Abspielen eines Standardsenders. Es kann zwar zu einem bestimmten Zeitpunkt nur ein Standardnetzwerk für eine App gelten, aber mit dieser Version kann Ihre App alle verfügbaren Netzwerke gleichzeitig sehen. Ein Aufruf von onLost(Network) bedeutet also, dass die Verbindung zum Netzwerk endgültig getrennt wurde und nicht, dass es nicht mehr das Standardnetzwerk ist.

Die App erstellt ein NetworkRequest, um ConnectivityManager darüber zu informieren, auf welche Art von Netzwerken sie warten möchte. Das folgende Beispiel zeigt, wie Sie ein NetworkRequest für eine App erstellen, die nur an Internetverbindungen ohne Zähler interessiert ist:

val request = NetworkRequest.Builder()
  .addCapability(NetworkCapabilities.NET_CAPABILITY_NOT_METERED)
  .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
  .build()

connectivityManager.registerNetworkCallback(request, myNetworkCallback)

NetworkRequest request = new NetworkRequest.Builder()
  .addCapability(NetworkCapabilities.NET_CAPABILITY_NOT_METERED)
  .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
  .build();

connectivityManager.registerNetworkCallback(request, myNetworkCallback);

Das bedeutet, dass Ihre App über alle Änderungen informiert wird, die sich auf ein beliebiges Netzwerk ohne Messung auf dem System beziehen.

Für den Standard-Netzwerk-Callback gibt es eine Version von registerNetworkCallback(NetworkRequest, NetworkCallback, Handler), die ein Handler akzeptiert, sodass der Connectivity-Thread Ihrer App nicht geladen wird.

Rufen Sie ConnectivityManager.unregisterNetworkCallback(NetworkCallback) auf, wenn der Callback nicht mehr relevant ist. Eine App kann gleichzeitig mehrere Netzwerk-Callbacks registrieren.

Das NetworkRequest-Objekt enthält die gängigen Funktionen, die die meisten Apps benötigen, darunter:

• NET_CAPABILITY_NOT_RESTRICTED
• NET_CAPABILITY_TRUSTED
• NET_CAPABILITY_NOT_VPN

Prüfen Sie beim Schreiben Ihrer App die Standardeinstellungen, um festzustellen, ob sie Ihrem Anwendungsfall entsprechen. Entfernen Sie sie, wenn Ihre App über Netzwerke benachrichtigt werden soll, die diese Funktionen nicht haben. Andererseits sollten Sie Funktionen hinzufügen, um nicht bei jeder Änderung der Konnektivität in Netzwerken aufgerufen zu werden, mit denen Ihre App nicht interagiert.

Wenn Ihre App beispielsweise MMS-Nachrichten senden muss, fügen Sie NET_CAPABILITY_MMS in NetworkRequest ein, um nicht über alle Netzwerke informiert zu werden, die keine MMS-Nachrichten senden können. Fügen Sie TRANSPORT_WIFI_AWARE hinzu, wenn Ihre App nur an P2P-WLAN-Verbindungen interessiert ist. NET_CAPABILITY_INTERNET und NET_CAPABILITY_VALIDATED sind hilfreich, wenn Sie Daten mit einem Server im Internet übertragen möchten.

Beispiel für eine Callback-Sequenz

In diesem Abschnitt wird die Reihenfolge der Callbacks beschrieben, die eine App erhalten kann, wenn sie sowohl einen Standard-Callback als auch einen regulären Callback auf einem Gerät mit Mobilfunkverbindung registriert. In diesem Beispiel verbindet sich das Gerät mit einem guten WLAN-Zugangspunkt und trennt dann die Verbindung. Im Beispiel wird auch davon ausgegangen, dass auf dem Gerät die Einstellung Mobile Datennutzung immer aktiviert aktiviert ist.

Die Zeitachse sieht so aus:

1. Wenn die App registerNetworkCallback() aufruft, empfängt der Callback sofort Anrufe von onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das Mobilfunknetz, da nur dieses Netzwerk verfügbar ist. Wenn ein anderes Netzwerk verfügbar ist, erhält die App auch Callbacks für das andere Netzwerk.

   
   Abbildung 1: App-Status nach dem Aufrufen von registerNetworkCallback().

2. Anschließend ruft die App registerDefaultNetworkCallback() auf. Der Standardnetzwerk-Callback empfängt Anrufe an onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das Mobilfunknetz, da es das Standardnetzwerk ist. Wenn ein anderes, nicht standardmäßiges Netzwerk aktiv ist, kann die App keine Anrufe für das nicht standardmäßige Netzwerk empfangen.

   
   Abbildung 2: App-Status nach der Registrierung eines Standardnetzwerks.

3. Später stellt das Gerät eine Verbindung zu einem WLAN her, das nicht nach Datenvolumen abgerechnet wird. Der reguläre Netzwerk-Callback empfängt Anrufe an onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das WLAN.

   
   Abbildung 3: App-Status nach der Verbindung mit einem WLAN, das nicht nach Datenvolumen abgerechnet wird.

4. Es kann eine Weile dauern, bis das WLAN validiert wird. In diesem Fall enthalten die onNetworkCapabilitiesChanged()-Aufrufe für den regulären Netzwerk-Callback nicht die Funktion NET_CAPABILITY_VALIDATED. Kurz darauf wird onNetworkCapabilitiesChanged() aufgerufen, wobei die neuen Funktionen NET_CAPABILITY_VALIDATED umfassen. In den meisten Fällen dauert die Bestätigung nur wenige Sekunden.

   Wenn das WLAN validiert wird, wird es vom System dem Mobilfunknetz vorgezogen, hauptsächlich weil es nicht abgerechnet wird. Das WLAN wird zum Standardnetzwerk. Der Standardnetzwerk-Callback empfängt also einen Aufruf an onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das WLAN. Das Mobilfunknetz wird in den Hintergrund verschoben und der reguläre Netzwerk-Callback empfängt einen Aufruf an onLosing() für das Mobilfunknetz.

   In diesem Beispiel wird davon ausgegangen, dass die mobilen Daten für dieses Gerät immer aktiviert sind. Daher wird die Verbindung zum Mobilfunknetz nie getrennt. Wenn die Einstellung deaktiviert ist, wird nach einer Weile die Verbindung zum Mobilfunknetz getrennt und der reguläre Netzwerk-Callback erhält einen Anruf an onLost().

   
   Abbildung 4: App-Status nach der Validierung des WLANs.

5. Später wird die Verbindung des Geräts zum WLAN plötzlich getrennt, weil es sich außerhalb der Reichweite befindet. Da die WLAN-Verbindung getrennt wird, erhält der reguläre Netzwerk-Callback einen Aufruf an onLost() für WLAN. Da das Mobilfunknetz das neue Standardnetzwerk ist, empfängt der Standardnetzwerk-Callback Aufrufe an onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das Mobilfunknetz.

   
   Abbildung 5: App-Status nach dem Trennen der WLAN-Verbindung.

Wenn die Einstellung Mobile Daten immer aktiv deaktiviert ist, versucht das Gerät, sich mit einem Mobilfunknetz zu verbinden, wenn die WLAN-Verbindung getrennt wird. Das Bild ist ähnlich, aber mit einer kurzen zusätzlichen Verzögerung für die onAvailable()-Anrufe. Der reguläre Netzwerk-Callback empfängt auch Anrufe an onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged(), da Mobilfunk verfügbar wird.

Einschränkungen bei der Nutzung des Netzwerks für die Datenübertragung

Wenn Sie ein Netzwerk mit einem Netzwerk-Callback sehen können, bedeutet das nicht, dass Ihre App das Netzwerk für die Datenübertragung verwenden kann. Einige Netzwerke bieten keine Internetverbindung und einige Netzwerke sind möglicherweise auf privilegierte Apps beschränkt. Informationen zum Prüfen der Internetverbindung finden Sie unter NET_CAPABILITY_INTERNET und NET_CAPABILITY_VALIDATED.

Die Verwendung von Hintergrundnetzwerken unterliegt ebenfalls Berechtigungsprüfungen. Wenn Ihre App ein Hintergrundnetzwerk verwenden möchte, benötigt sie die Berechtigung CHANGE_NETWORK_STATE.

Apps mit dieser Berechtigung können das System veranlassen, ein Netzwerk zu aktivieren, das nicht aktiv ist, z. B. das Mobilfunknetz, wenn das Gerät mit einem WLAN verbunden ist. Eine solche App ruft ConnectivityManager.requestNetwork(NetworkRequest, NetworkCallback) mit einem NetworkCallback auf, das aufgerufen werden soll, wenn das Netzwerk eingerichtet wird.