Netzwerkstatus lesen

Mit Android können Apps dynamische Veränderungen bei der Konnektivität erkennen. Mit den folgenden Klassen können Sie Verbindungsänderungen verfolgen und darauf reagieren:

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

Anwendungen, die an der unmittelbaren Verbindung zu einem bestimmten Zeitpunkt interessiert sind, können ConnectivityManager-Methoden aufrufen, um herauszufinden, welche Art von Netzwerk verfügbar ist. Diese Methoden sind hilfreich für das Debugging und um gelegentlich eine Momentaufnahme der Verbindung zu prüfen, die zu einem bestimmten Zeitpunkt verfügbar ist.

Die synchronen ConnectivityManager-Methoden informieren Ihre Anwendung jedoch nicht darüber, was nach einem Aufruf passiert. Daher können Sie die UI nicht aktualisieren. Außerdem können sie das Anwendungsverhalten nicht auf Grundlage der Trennung des Netzwerks oder der Änderung der Netzwerkfunktionen anpassen.

Die Konnektivität kann sich jederzeit ändern und die meisten Anwendungen benötigen eine immer aktuelle, aktuelle Ansicht des Netzwerkstatus auf dem Gerät. Anwendungen können einen Callback mit ConnectivityManager registrieren, um über Änderungen informiert zu werden, die für die Anwendung relevant sind. Mithilfe des Callbacks kann Ihre Anwendung sofort auf jede relevante Änderung der Konnektivität reagieren, ohne auf teure Abfragen zurückgreifen zu müssen, bei denen schnelle Updates möglicherweise übersehen werden.

Die Verwendung von NetworkCallback und anderen Möglichkeiten, den Verbindungsstatus des Geräts herauszufinden, erfordert keine bestimmte Berechtigung. Einige Netzwerke unterliegen jedoch bestimmten Berechtigungen. Es kann beispielsweise sein, dass eingeschränkte Netzwerke für Anwendungen nicht verfügbar sind. Für eine Bindung an ein Hintergrundnetzwerk ist die Berechtigung CHANGE_NETWORK_STATE erforderlich. Für einige Aufrufe sind möglicherweise bestimmte Berechtigungen erforderlich. Einzelheiten finden Sie in der Dokumentation der einzelnen Aufrufe.

Aktuellen Status abrufen

Ein Android-Gerät kann viele Verbindungen gleichzeitig aufrechterhalten. Um Informationen zum aktuellen Netzwerkstatus zu erhalten, rufen Sie zuerst eine Instanz von ConnectivityManager ab:

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

ConnectivityManager connectivityManager = getSystemService(ConnectivityManager.class);

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

val currentNetwork = connectivityManager.getActiveNetwork()

Network currentNetwork = connectivityManager.getActiveNetwork();

Mit Bezug auf ein Netzwerk kann Ihre App Informationen zu diesem Netzwerk anfordern:

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

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

Registrieren Sie eine NetworkCallback, um weitere nützliche Funktionen zu erhalten. Weitere Informationen zum Registrieren von Netzwerk-Callbacks finden Sie unter Auf Netzwerkereignisse warten.

NetworkCapabilities und LinkProperties

Die Objekte NetworkCapabilities und LinkProperties bieten Informationen über alle Attribute, die dem System über ein Netzwerk bekannt sind.

Das LinkProperties-Objekt kennt die Routen, Linkadressen, 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 über das Netzwerk transports und seine Funktionen.

Ein Transport ist eine Abstraktion eines physischen Mediums, über das ein Netzwerk betrieben wird. Gängige Beispiele für Übertragungen sind Ethernet, WLAN und Mobilgeräte. VPNs und Peer-to-Peer-WLAN können ebenfalls Übertragungen sein. Auf Android-Geräten können für ein Netzwerk mehrere Übertragungen gleichzeitig ausgeführt werden. Ein Beispiel hierfür ist ein VPN, das sowohl über WLAN als auch über Mobilfunknetze betrieben wird. Das VPN umfasst die WLAN-, Mobil- und VPN-Transporte. 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 Capability beschreibt eine Eigenschaft des Netzwerks. Beispiele für Funktionen sind MMS, NOT_METERED und INTERNET. Ein Netzwerk mit der MMS-Funktion kann Multimedia Messaging-Dienst-Nachrichten senden und empfangen, ein Netzwerk ohne diese Fähigkeit jedoch nicht. Ein Netzwerk mit der Funktion NOT_METERED stellt dem Nutzer keine Daten in Rechnung. Ihre Anwendung kann mithilfe der Methode NetworkCapabilities.hasCapability(int) mit 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 Zugriff auf das Internet eingerichtet ist. Hier geht es um die Einrichtung und nicht um die Möglichkeit, öffentliche Server zu erreichen. Beispielsweise kann ein Netzwerk für den Zugriff auf das Internet eingerichtet werden, aber einem Captive Portal unterliegen.

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

• NET_CAPABILITY_NOT_METERED: zeigt an, dass das Netzwerk nicht kostenpflichtig ist. Ein Netzwerk wird als "kostenpflichtig" eingestuft, wenn der Nutzer aufgrund von finanziellen Kosten, Dateneinschränkungen oder Problemen mit der Akkuleistung empfindlich auf eine hohe Datennutzung für 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 tatsächlichen Zugriff auf das öffentliche Internet bietet, wenn es geprüft wird. Ein Netzwerk hinter einem Captive Portal oder ein Netzwerk, das keine Auflösung von Domainnamen bietet, hat diese Möglichkeit nicht. Dies ist die nächste, die das System über ein Netzwerk informieren kann, das tatsächlich Zugriff gewährt. Ein validiertes Netzwerk kann jedoch grundsätzlich IP-basierter Filterung unterliegen oder plötzliche Verbindungsverluste aufgrund von Problemen wie schlechten Signalen haben.

• NET_CAPABILITY_CAPTIVE_PORTAL: gibt an, dass das Netzwerk ein Captive Portal hat, wenn es geprüft wird.

Es gibt noch andere Funktionen, die für speziellere Apps interessant sein könnten. Weitere Informationen finden Sie in den Parameterdefinitionen in 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ährenddessen hat das Netzwerk die Funktionen NET_CAPABILITY_INTERNET und NET_CAPABILITY_CAPTIVE_PORTAL, aber nicht die Funktionen NET_CAPABILITY_VALIDATED.

Wenn der Nutzer eine Aktion ausführt und sich auf der Captive Portal-Seite anmeldet, kann das Gerät auf das öffentliche Internet zugreifen und das Netzwerk erhält die NET_CAPABILITY_VALIDATED-Funktion und verliert die NET_CAPABILITY_CAPTIVE_PORTAL-Funktion.

Ebenso können sich die Transporte eines Netzwerks dynamisch ändern. Ein VPN kann sich beispielsweise neu konfigurieren, um ein schnelleres Netzwerk zu verwenden, das gerade erstellt wurde, z. B. ein Wechsel von einem Mobilfunknetz zu einem WLAN für das zugrunde liegende Netzwerk. 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

Wenn Sie mehr über Netzwerkereignisse erfahren möchten, verwenden Sie die Klasse NetworkCallback zusammen mit ConnectivityManager.registerDefaultNetworkCallback(NetworkCallback) und ConnectivityManager.registerNetworkCallback(NetworkCallback). Diese beiden Methoden dienen unterschiedlichen Zwecken.

Alle Android-Apps haben ein Standardnetzwerk, das vom System bestimmt wird. Das System bevorzugt in der Regel kostenlose Netzwerke gegenüber kostenpflichtigen Netzwerken und schnellere als langsamere.

Wenn eine Anwendung eine Netzwerkanfrage ausgibt, z. B. mit HttpsURLConnection, erfüllt das System diese Anfrage mit dem Standardnetzwerk. Apps können auch Traffic über andere Netzwerke senden. Weitere Informationen finden Sie im Abschnitt über zusätzliche Netzwerke.

Das als Standardnetzwerk festgelegte Netzwerk kann sich während der Lebensdauer einer App jederzeit ändern. Ein typisches Beispiel ist das Gerät, das sich in Reichweite eines bekannten, aktiven, nicht getakteten und schneller als ein mobilen WLAN-Zugangspunkts befindet. Das Gerät stellt eine Verbindung zu diesem Zugangspunkt her und stellt das Standardnetzwerk für alle Apps auf das neue WLAN um.

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

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 Standard wird, empfängt die Anwendung 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 Konnektivität zu reagieren.

Bei einem mit registerDefaultNetworkCallback() registrierten Callback bedeutet onLost(), dass das Netzwerk den Status als Standardnetzwerk verloren hat. Möglicherweise ist die Verbindung getrennt.

Sie können zwar durch Abfrage von NetworkCapabilities.hasTransport(int) mehr über die Transporte erfahren, die das Standardnetzwerk verwendet, aber dies ist ein schlechter Proxy für die Bandbreite oder den Messumfang des Netzwerks. Ihre App kann nicht davon ausgehen, dass das WLAN immer kostenlos ist und immer eine bessere Bandbreite als mobile Daten bereitstellt.

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

Standardmäßig werden die Callback-Methoden im Verbindungsthread Ihrer Anwendung aufgerufen. Dabei handelt es sich um einen separaten Thread, der von ConnectivityManager verwendet wird. Wenn Ihre Implementierung der Callbacks nicht mehr funktionieren muss, rufen Sie sie mithilfe der Variante ConnectivityManager.registerDefaultNetworkCallback(NetworkCallback, Handler) in einem separaten Worker-Thread auf.

Heben Sie die Registrierung Ihres Callbacks auf, wenn Sie ihn nicht mehr verwenden. Rufen Sie dazu ConnectivityManager.unregisterNetworkCallback(NetworkCallback) auf. Dafür eignet sich die onPause() deiner Hauptaktivität, insbesondere wenn du den Callback in onResume() registrierst.

Zusätzliche Netzwerke

Obwohl das Standardnetzwerk das einzige relevante Netzwerk für die meisten Anwendungen ist, sind einige Anwendungen möglicherweise an anderen verfügbaren Netzwerken interessiert. Dazu erstellen Anwendungen eine NetworkRequest, die ihren Anforderungen entspricht, und rufen ConnectivityManager.registerNetworkCallback(NetworkRequest, NetworkCallback) auf.

Dieser Vorgang ähnelt dem Überwachen eines Standardnetzwerks. Obwohl es immer nur ein Standardnetzwerk geben kann, das jeweils für eine Anwendung gilt, kann Ihre Anwendung mit dieser Version alle verfügbaren Netzwerke gleichzeitig sehen. Ein Aufruf von onLost(Network) bedeutet also, dass die Verbindung zum Netzwerk dauerhaft getrennt wurde und dass es nicht mehr zum Standardnetzwerk gehört.

Die App erstellt eine NetworkRequest, um ConnectivityManager darüber zu informieren, welche Art von Netzwerken sie überwachen möchte. Das folgende Beispiel zeigt, wie Sie eine NetworkRequest für eine Anwendung erstellen, die nur an nicht getakteten Internetverbindungen 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 alle Änderungen in Bezug auf nicht getaktete Netzwerke im System erfährt.

Was den Standardnetzwerk-Callback angeht, gibt es eine Version von registerNetworkCallback(NetworkRequest, NetworkCallback, Handler), die Handler akzeptiert, sodass der Connectivity-Thread Ihrer Anwendung nicht geladen wird.

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

Der Einfachheit halber enthält das NetworkRequest-Objekt die allgemeinen Funktionen, die die meisten Anwendungen benötigen. Dazu gehören:

• NET_CAPABILITY_NOT_RESTRICTED
• NET_CAPABILITY_TRUSTED
• NET_CAPABILITY_NOT_VPN

Prüfen Sie beim Schreiben Ihrer Anwendung die Standardeinstellungen, um festzustellen, ob sie zu Ihrem Anwendungsfall passen. Löschen Sie sie, wenn Ihre App über Netzwerke benachrichtigt werden soll, die diese Funktionen nicht haben. Fügen Sie andererseits Funktionen hinzu, um zu verhindern, dass bei Verbindungsänderungen in Netzwerken aufgerufen wird, mit denen Ihre App nicht interagiert.

Wenn Ihre Anwendung beispielsweise MMS senden muss, fügen Sie NET_CAPABILITY_MMS in NetworkRequest ein. So werden Sie nicht über alle Netzwerke informiert, die keine MMS senden können. Füge TRANSPORT_WIFI_AWARE hinzu, wenn deine 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 stellt das Gerät eine Verbindung zu einem guten WLAN-Zugangspunkt her und trennt sich dann wieder von diesem. In diesem Beispiel wird außerdem davon ausgegangen, dass auf dem Gerät die Einstellung Mobile Daten immer an aktiviert ist.

Der Zeitplan sieht so aus:

1. Wenn die App registerNetworkCallback() aufruft, erhält 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, empfängt die App auch Callbacks für dieses Netzwerk.

   
   Abbildung 1: App-Status nach dem Aufruf 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 das Mobilfunknetz das Standardnetzwerk ist. Wenn ein anderes, nicht standardmäßiges Netzwerk aktiv ist, kann die Anwendung keine Aufrufe 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 (kostenlosen) WLAN her. Der reguläre Netzwerk-Callback empfängt Aufrufe an onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das WLAN.

   
   Abbildung 3: App-Status nach dem Verbinden mit einem nicht getakteten WLAN

4. An dieser Stelle kann es eine Weile dauern, bis das WLAN validiert ist. In diesem Fall enthalten die onNetworkCapabilitiesChanged()-Aufrufe für den regulären Netzwerkrückruf nicht die Funktion NET_CAPABILITY_VALIDATED. Nach kurzer Zeit erhält er einen Aufruf von onNetworkCapabilitiesChanged(), wobei die neuen Funktionen NET_CAPABILITY_VALIDATED enthalten. In den meisten Fällen erfolgt die Validierung sehr schnell.

   Wenn das WLAN validiert wird, bevorzugt das System es dem Mobilfunknetz, hauptsächlich weil es nicht getaktet ist. Das WLAN wird zum Standardnetzwerk, sodass der Standard-Netzwerk-Callback einen Aufruf an onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das WLAN empfängt. Das Mobilfunknetz geht in den Hintergrund und der reguläre Netzwerk-Callback empfängt einen Aufruf an onLosing() für das Mobilfunknetz.

   Da in diesem Beispiel angenommen wird, dass die mobilen Daten für dieses Gerät immer aktiviert sind, wird das 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 Aufruf an onLost().

   
   Abbildung 4: App-Status nach Validierung des WLAN-Netzwerks.

5. Später wird das Gerät plötzlich vom WLAN getrennt, weil es nicht in Reichweite war. Da die WLAN-Verbindung getrennt wird, empfängt der reguläre Netzwerk-Callback einen WLAN-Aufruf an onLost(). Da Mobilgeräte das neue Standardnetzwerk sind, empfängt der Standardnetzwerk-Callback onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das Mobilfunknetz.

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

Wenn die Einstellung Mobile Daten immer aktiviert deaktiviert ist, versucht das Gerät, sich wieder 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()-Aufrufe. Der reguläre Netzwerk-Callback empfängt außerdem Aufrufe an onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged(), da ein Mobilgerät verfügbar wird.

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

Wenn ein Netzwerk mit einem Netzwerk-Callback angezeigt wird, bedeutet dies nicht, dass Ihre Anwendung das Netzwerk für die Datenübertragung verwenden kann. Einige Netzwerke bieten keine Internetverbindung und andere sind möglicherweise auf privilegierte Anwendungen beschränkt. Informationen zum Prüfen der Internetverbindung finden Sie unter NET_CAPABILITY_INTERNET und NET_CAPABILITY_VALIDATED.

Bei der Verwendung von Hintergrundnetzwerken müssen auch Berechtigungsprüfungen durchgeführt werden. Wenn Ihre App ein Hintergrundnetzwerk verwenden möchte, ist die Berechtigung CHANGE_NETWORK_STATE erforderlich.

Bei Apps mit dieser Berechtigung kann das System versuchen, ein Netzwerk aufzurufen, das nicht aktiv ist, z. B. das Mobilfunknetz, wenn das Gerät mit einem WLAN verbunden ist. Eine solche Anwendung ruft ConnectivityManager.requestNetwork(NetworkRequest, NetworkCallback) mit einer NetworkCallback auf, die aufgerufen wird, wenn das Netzwerk aktiviert wird.