Netzwerkstatus lesen

Android ermöglicht es Apps, dynamische Änderungen der Konnektivität zu erkennen. Verwenden Sie die folgenden Klassen, um Konnektivitätsänderungen zu verfolgen und darauf zu reagieren:

• ConnectivityManager informiert Ihre App über den Status der Konnektivität 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 Verbindung zum Netzwerk getrennt wird, kann das Network-Objekt nicht mehr verwendet werden. Auch wenn das Gerät später wieder eine Verbindung mit demselben Gerät herstellt, 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 wurden.
• Das NetworkCapabilities Objekt enthält Informationen zu den Eigenschaften eines Netzwerks, z. B. zu den Transporten (WLAN, Mobilfunk, Bluetooth) und zu den Möglichkeiten des Netzwerks. Sie können das Objekt beispielsweise abfragen, um zu ermitteln, ob das Netzwerk MMS senden kann, sich hinter einem Captive Portal befindet oder kostenpflichtig ist.

Apps, die den aktuellen Status der Konnektivität jederzeit abrufen möchten, können ConnectivityManager-Methoden aufrufen, um zu ermitteln, welche Art von Netzwerk verfügbar ist. Diese Methoden sind hilfreich für das Debugging und um gelegentlich eine Momentaufnahme der verfügbaren Konnektivität zu einem bestimmten Zeitpunkt zu überprüfen.

Die synchronen ConnectivityManager-Methoden informieren Ihre App jedoch nicht über Ereignisse nach einem Anruf, sodass Sie die UI nicht aktualisieren können. Außerdem können sie das App-Verhalten nicht anpassen, wenn die Verbindung zum Netzwerk getrennt 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 einen Callback bei ConnectivityManager registrieren, um über Änderungen informiert zu werden, die für die App relevant sind. Mit dem Callback kann Ihre App sofort auf relevante Änderungen der Konnektivität 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 andere Möglichkeiten, den Konnektivitätsstatus des Geräts zu ermitteln, ist keine bestimmte Berechtigung erforderlich. Für einige Netzwerke gelten jedoch bestimmte Berechtigungen. Es gibt beispielsweise eingeschränkte Netzwerke, die für Apps nicht verfügbar sind. Für die Bindung an ein Hintergrundnetzwerk ist die Berechtigung CHANGE_NETWORK_STATE erforderlich. Für einige Anrufe sind möglicherweise bestimmte Berechtigungen erforderlich. Weitere Informationen finden Sie in der jeweiligen Dokumentation für jeden Anruf.

Sofortigen Status abrufen

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

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 abzurufen:

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

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

NetworkCapabilities und LinkProperties

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

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

Das Objekt NetworkCapabilities kapselt Informationen zu den Transporten des Netzwerks und deren Funktionen.

Ein Transport ist eine Abstraktion eines physischen Mediums, über das ein Netzwerk funktioniert. Gängige Beispiele für Transporte sind Ethernet, WLAN und Mobilfunk. VPNs und Peer-to-Peer-WLAN können ebenfalls Transporte sein. Unter Android kann ein Netzwerk gleichzeitig mehrere Transporte haben. Ein Beispiel dafür ist ein VPN, das sowohl über WLAN als auch über Mobilfunknetze funktioniert. Das VPN hat die Transporte WLAN, Mobilfunk und VPN. Verwenden Sie die NetworkCapabilities.hasTransport(int) Methode mit einer der NetworkCapabilities.TRANSPORT_* Konstanten, um herauszufinden, ob ein Netzwerk einen bestimmten Transport hat.

Eine Funktion beschreibt eine Eigenschaft des Netzwerks. Beispiele für Funktionen sind MMS, NOT_METERED und INTERNET. Ein Netzwerk mit der Funktion „MMS“ kann MMS-Nachrichten senden und empfangen, ein Netzwerk ohne diese Funktion nicht. Bei einem Netzwerk mit der Funktion NOT_METERED werden dem Nutzer keine Datengebühren berechnet. Ihre App kann mit der NetworkCapabilities.hasCapability(int) Methode und einer der NetworkCapabilities.NET_CAPABILITY_* Konstanten nach geeigneten Funktionen suchen.

Die nützlichsten Konstanten NET_CAPABILITY_* sind:

• NET_CAPABILITY_INTERNET: Gibt an, dass das Netzwerk für den Zugriff auf das Internet eingerichtet ist. Es geht hier um die Einrichtung und nicht um die tatsächliche Fähigkeit, öffentliche Server zu erreichen. Ein Netzwerk kann beispielsweise für den Zugriff auf das Internet eingerichtet sein, aber einem Captive Portal unterliegen.

  Das Mobilfunknetz eines Mobilfunkanbieters hat in der Regel die Funktion INTERNET, während ein lokales P2P-WLAN in der Regel nicht über diese Funktion verfügt. Informationen zur tatsächlichen Konnektivität finden Sie unter NET_CAPABILITY_VALIDATED.

• NET_CAPABILITY_NOT_METERED: Gibt an, dass das Netzwerk nicht kostenpflichtig ist. Ein Netzwerk wird als kostenpflichtig 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 der Überprüfung tatsächlichen Zugriff auf das öffentliche Internet bietet. Ein Netzwerk hinter einem Captive Portal oder ein Netzwerk, das keine Domainnamensauflösung bietet, hat diese Funktion nicht. Dies ist die genaueste Aussage, die das System darüber machen kann, ob ein Netzwerk tatsächlich Zugriff bietet. Ein validiertes 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 spezialisiertere Apps von Interesse 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 dieses Vorgangs hat das Netzwerk die Funktionen NET_CAPABILITY_INTERNET und NET_CAPABILITY_CAPTIVE_PORTAL, aber nicht 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 Funktion NET_CAPABILITY_VALIDATED und verliert die Funktion NET_CAPABILITY_CAPTIVE_PORTAL.

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 verfügbar geworden ist, z. B. von Mobilfunk zu WLAN für das zugrunde liegende Netzwerk wechseln. In diesem Fall verliert das Netzwerk den Transport TRANSPORT_CELLULAR und erhält den Transport TRANSPORT_WIFI, behält aber den Transport TRANSPORT_VPN.

Auf Netzwerkereignisse warten

Verwenden Sie die NetworkCallback Klasse zusammen mit ConnectivityManager.registerDefaultNetworkCallback(NetworkCallback) und ConnectivityManager.registerNetworkCallback(NetworkCallback), um Informationen zu Netzwerkereignissen zu erhalten. Diese beiden Methoden dienen unterschiedlichen Zwecken.

Alle Android-Apps haben ein Standardnetzwerk, das vom System festgelegt wird. Das System bevorzugt in der Regel Netzwerke ohne Datenlimit gegenüber kostenpflichtigen Netzwerken und schnellere Netzwerke gegenüber langsameren.

Wenn eine App eine Netzwerkanfrage stellt, z. B. mit HttpsURLConnection, erfüllt das System diese Anfrage über das Standardnetzwerk. 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 während der Lebensdauer einer App ändern. Ein typisches Beispiel ist, wenn sich das Gerät in Reichweite eines bekannten, aktiven, ohne Datenlimit und schnelleren WLAN-Zugangspunkts befindet. 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 Standard wird, wird für jede neue Verbindung, die die App öffnet, dieses Netzwerk verwendet. Zu einem späteren Zeitpunkt 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 Standard wird, erhält die App einen Aufruf von onAvailable(Network) für das neue Netzwerk. Implementieren Sie onCapabilitiesChanged(Network,NetworkCapabilities), onLinkPropertiesChanged(Network,LinkProperties), oder beide, um angemessen auf Änderungen der Konnektivität zu reagieren.

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

Sie können zwar die Transporte abrufen, die das Standardnetzwerk verwendet, indem Sie abfragen NetworkCapabilities.hasTransport(int), dies ist jedoch kein guter Proxy für die Bandbreite oder die Kostenpflichtigkeit des Netzwerks. Ihre App kann nicht davon ausgehen, dass WLAN immer ohne Datenlimit 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 Kostenpflichtigkeit zu ermitteln. Weitere Informationen finden Sie im Abschnitt zu NetworkCapabilities und LinkProperties.

Standardmäßig werden die Callback-Methoden im Konnektivitäts-Thread Ihrer App aufgerufen. Dies ist ein separater Thread, der von ConnectivityManager verwendet wird. Wenn für die Implementierung der Callbacks längere Aufgaben erforderlich sind, rufen Sie sie in einem separaten Arbeitsthread auf. Verwenden Sie dazu die Variante ConnectivityManager.registerDefaultNetworkCallback(NetworkCallback, Handler).

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

Zusätzliche Netzwerke (komplexere Anwendungsfälle)

Obwohl das Standardnetzwerk für die meisten Apps das einzige relevante Netzwerk ist, könnten einige Apps an anderen verfügbaren Netzwerken interessiert sein. Um diese zu ermitteln, erstellen Apps eine NetworkRequest, die ihren Anforderungen entspricht, und rufen ConnectivityManager.registerNetworkCallback(NetworkRequest, NetworkCallback) auf.

Der Vorgang ähnelt dem Warten auf ein Standardnetzwerk. Es kann jedoch nur ein Standardnetzwerk geben, das zu einem bestimmten Zeitpunkt für eine App gilt. 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, nicht dass es nicht mehr das Standardnetzwerk ist.

Die App erstellt eine NetworkRequest, um ConnectivityManager darüber zu informieren, auf welche Art von Netzwerken sie warten möchte. Das folgende Beispiel zeigt, wie eine NetworkRequest für eine App erstellt wird, die nur an Internetverbindungen ohne Datenlimit 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 ein kostenloses Netzwerk im System betreffen.

Wie beim Standardnetzwerk-Callback gibt es eine Version von registerNetworkCallback(NetworkRequest, NetworkCallback, Handler) , die einen Handler akzeptiert, sodass der Connectivity Thread Ihrer App nicht belastet 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. Fügen Sie andererseits Funktionen hinzu, um zu vermeiden, dass Sie bei jeder Änderung der Konnektivität in Netzwerken benachrichtigt werden, mit denen Ihre App nicht interagiert.

Wenn Ihre App beispielsweise MMS-Nachrichten senden muss, fügen Sie NET_CAPABILITY_MMS zur NetworkRequest hinzu, 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 Sequenz von 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 dann die Verbindung. Außerdem wird 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, erhält der Callback sofort Aufrufe 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 Aufruf von registerNetworkCallback().

2. Anschließend ruft die App registerDefaultNetworkCallback() auf. Der Standardnetzwerk-Callback erhält Aufrufe von 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 App keine Aufrufe für das nicht standardmäßige Netzwerk erhalten.

   
   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 erhält Aufrufe von onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das WLAN.

   
   Abbildung 3. App-Status nach der Verbindung mit einem kostenlosen WLAN.

4. An diesem Punkt kann es 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. 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 gegenüber dem Mobilfunknetz, hauptsächlich weil es ohne Datenlimit ist. Das WLAN wird zum Standardnetzwerk. Der Standardnetzwerk-Callback erhält also einen Aufruf von onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das WLAN. Das Mobilfunknetz wird in den Hintergrund verschoben und der reguläre Netzwerk-Callback erhält einen Aufruf von onLosing() für das Mobilfunknetz.

   Da in diesem Beispiel davon ausgegangen wird, dass die mobile Datennutzung für dieses Gerät immer aktiviert ist, wird die Verbindung zum Mobilfunknetz nie getrennt. Wenn die Einstellung deaktiviert ist, wird die Verbindung zum Mobilfunknetz nach einiger Zeit getrennt und der reguläre Netzwerk-Callback erhält einen Aufruf von onLost().

   
   Abbildung 4. App-Status nach der Validierung des WLAN.

5. Später wird die Verbindung zum WLAN plötzlich getrennt, weil das Gerät außer Reichweite ist. Da die Verbindung zum WLAN getrennt wird, erhält der reguläre Netzwerk-Callback einen Aufruf von onLost() für WLAN. Da Mobilfunk das neue Standardnetzwerk ist, erhält der Standardnetzwerk-Callback Aufrufe von onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das Mobilfunknetz.

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

Wenn die Einstellung Mobile Datennutzung immer aktiviert deaktiviert ist, versucht das Gerät nach dem Trennen der Verbindung zum WLAN, eine Verbindung zu einem Mobilfunknetz herzustellen. Das Bild ist ähnlich, aber mit einer kurzen zusätzlichen Verzögerung für die onAvailable()-Aufrufe. Der reguläre Netzwerk-Callback erhält auch Aufrufe von onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged(), da Mobilfunk verfügbar wird.

Einschränkungen bei der Verwendung 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 zur 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 CHANGE_NETWORK_STATE Berechtigung.

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, der aufgerufen werden soll, wenn das Netzwerk aktiviert wird.