Netzwerkstatus lesen

Android ermöglicht es Apps, dynamische Änderungen der Konnektivität zu erkennen. Verwenden Sie die folgenden Klassen, um Änderungen an der Verbindung zu verfolgen 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 über das 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 derselben Appliance verbunden wird, stellt ein neues Network-Objekt das neue Netzwerk dar.
• Das Objekt LinkProperties enthält Informationen zur Verbindung für ein Netzwerk, z. B. die Liste der DNS-Server, lokale IP-Adressen und Netzwerkrouten, die für das Netzwerk installiert sind.
• Das NetworkCapabilities-Objekt enthält Informationen zu den Eigenschaften eines Netzwerks, z. B. zu den Übertragungsarten (WLAN, Mobilfunk, Bluetooth) und zu den Funktionen des Netzwerks. Du kannst das Objekt beispielsweise abfragen, um festzustellen, ob das Netzwerk MMS senden kann, sich hinter einem Captive Portal befindet oder getaktet ist.

Apps, die den aktuellen Verbindungsstatus zu einem bestimmten Zeitpunkt abrufen möchten, 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 einen Snapshot der zu einem bestimmten Zeitpunkt verfügbaren Konnektivität zu überprüfen.

Die synchronen ConnectivityManager-Methoden informieren Ihre App jedoch nicht über Ereignisse nach einem Aufruf. Sie können Ihre UI also nicht aktualisieren. Sie können auch das App-Verhalten nicht anpassen, wenn die Netzwerkverbindung getrennt wird oder sich die Netzwerkfunktionen ändern.

Die Konnektivität kann sich jederzeit ändern. Die meisten Apps benötigen eine 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 alle relevanten Änderungen der Verbindung reagieren, ohne dass ein aufwendiges Polling erforderlich ist, bei dem schnelle Aktualisierungen möglicherweise nicht erkannt werden.

Hinweis: Wenn deine App Aufgaben für den Zeitpunkt planen muss, an dem das Gerät das nächste Mal eine Verbindung hat oder sich in einem Netzwerk ohne Datenlimit befindet, z. B. für Hintergrunddownloads, lies stattdessen den Artikel zu WorkManager. ConnectivityManager informiert Sie zwar über diese Zustände, aber mit WorkManager kann Ihre App ihre Jobs zu geeigneteren Zeiten mit feinerer Kontrolle und mit viel weniger Aufwand ausführen.

Für die Verwendung von NetworkCallback und anderen Möglichkeiten, den Verbindungsstatus des Geräts zu ermitteln, ist keine bestimmte Berechtigung erforderlich. Für einige Netzwerke gelten jedoch bestimmte Berechtigungen. Beispielsweise kann es eingeschränkte Netzwerke geben, 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 Aufrufe sind möglicherweise bestimmte Berechtigungen erforderlich. Weitere Informationen finden Sie in der Dokumentation zum jeweiligen Aufruf.

Aktuellen Status abrufen

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

Kotlin

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

Java

ConnectivityManager connectivityManager = getSystemService(ConnectivityManager.class);

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

Kotlin

val currentNetwork = connectivityManager.getActiveNetwork()

Java

Network currentNetwork = connectivityManager.getActiveNetwork();

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

Kotlin

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

Java

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

Wenn Sie weitere nützliche Funktionen nutzen möchten, registrieren Sie einen NetworkCallback. 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 dem System zu einem Netzwerk bekannt sind.

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

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

Ein Transport ist eine Abstraktion eines physischen Mediums, über das ein Netzwerk betrieben wird. Gängige Beispiele für Übertragungsmedien sind Ethernet, WLAN und Mobilfunk. VPNs und Peer-to-Peer-WLAN können ebenfalls als Transportmittel dienen. Unter Android kann ein Netzwerk mehrere Übertragungen gleichzeitig haben. Ein Beispiel hierfür ist ein VPN, das sowohl über WLAN als auch über Mobilfunknetze funktioniert. Das VPN hat die Transporte 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. Ein Netzwerk mit der MMS-Funktion kann Multimedia Messaging Service-Nachrichten senden und empfangen, ein Netzwerk ohne diese Funktion nicht. In einem Netzwerk mit der Funktion NOT_METERED werden dem Nutzer keine Daten in Rechnung gestellt. Ihre App kann mit der Methode NetworkCapabilities.hasCapability(int) und einer der NetworkCapabilities.NET_CAPABILITY_*-Konstanten nach geeigneten Funktionen suchen.

Zu den nützlichsten NET_CAPABILITY_*-Konstanten gehören:

• 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 tatsächliche Fähigkeit, öffentliche Server zu erreichen. Ein Netzwerk kann beispielsweise so eingerichtet werden, dass es auf das Internet zugreift, aber einem Captive Portal unterliegt.

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

• NET_CAPABILITY_NOT_METERED: Gibt an, dass das Netzwerk nicht gemessen wird. 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 der Prüfung tatsächlichen Zugriff auf das öffentliche Internet bietet. Ein Netzwerk hinter einem Captive Portal oder ein Netzwerk, das keine Domainnamenauflösung bietet, hat diese Funktion nicht. Dies ist die genaueste Angabe, die das System darüber machen kann, ob ein Netzwerk tatsächlich Zugriff bietet. Ein validiertes Netzwerk kann jedoch grundsätzlich weiterhin einer IP-basierten Filterung 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 Prüfung ein Captive Portal hat.

Es gibt noch weitere Funktionen, die für spezialisiertere 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ährend dieses Vorgangs 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 die erforderlichen Schritte ausführt 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 so konfigurieren, dass es ein schnelleres Netzwerk verwendet, das gerade verfügbar geworden ist, z. B. 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.

Netzwerkereignisse beobachten

Informationen zu Netzwerkereignissen erhalten Sie mit der 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 festgelegt wird. Das System bevorzugt in der Regel Netzwerke ohne Datenlimit gegenüber Netzwerken mit Datenlimit und schnellere Netzwerke gegenüber langsameren.

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

Das Netzwerk, das als Standardnetzwerk festgelegt ist, kann sich während der Lebensdauer einer App jederzeit ändern. Ein typisches Beispiel ist, wenn das Gerät in die Reichweite eines bekannten, aktiven, ohne Datenlimit und schnelleren WLAN-Zugangspunkts kommt. Das Gerät stellt eine Verbindung zu diesem Zugangspunkt her und wechselt das Standardnetzwerk für alle Apps zum neuen WLAN.

Wenn ein neues Netzwerk zum Standardnetzwerk wird, verwendet jede neue Verbindung, die die App öffnet, dieses Netzwerk. 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 wie folgt:

Kotlin

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

Java

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.

Achtung: Rufe nicht die synchronen Methoden auf, um im Callback Informationen zu den Eigenschaften eines neu verfügbaren Netzwerks zu erhalten, da dies zu Race-Bedingungen führt. Warte stattdessen auf Aufrufe von onCapabilitiesChanged() und onLinkPropertiesChanged() für dieses Netzwerk, die auf Geräten mit Android 8.0 (API-Level 26) und höher sofort nach onAvailable() aufgerufen werden.

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 vom Standardnetzwerk verwendeten Transporte durch Abfragen von NetworkCapabilities.hasTransport(int) ermitteln, dies ist jedoch ein schlechter Proxy für die Bandbreite oder die Messung des Netzwerks. Ihre App kann nicht davon ausgehen, dass WLAN immer ohne Datenlimit ist und immer eine bessere Bandbreite als mobile Daten bietet.

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

Standardmäßig werden die Callback-Methoden im Verbindungsthread Ihrer App aufgerufen. Dies ist ein separater Thread, der von ConnectivityManager verwendet wird. Wenn die Implementierung der Callbacks länger dauert, rufen Sie sie mit der Variante ConnectivityManager.registerDefaultNetworkCallback(NetworkCallback, Handler) in einem separaten Arbeitsthread auf.

Wenn Sie den Callback nicht mehr benötigen, können Sie die Registrierung mit ConnectivityManager.unregisterNetworkCallback(NetworkCallback) aufheben. Die onPause()-Methode der Hauptaktivität ist dafür gut geeignet, insbesondere wenn Sie den Callback in onResume() registrieren.

Hinweis: Die Anzahl der Callbacks, die gleichzeitig registriert werden können, ist begrenzt. Heben Sie die Registrierung von Callbacks auf, sobald sie nicht mehr benötigt werden, damit Ihre App weitere registrieren kann.

Zusätzliche Netzwerke (erweiterte Anwendungsfälle)

Achtung: Für die meisten Anwendungen müssen keine zusätzlichen Netzwerke verwendet werden. Stattdessen sollte das Standardnetzwerk verwendet werden. Nur Apps, die andere Netzwerke verwenden müssen, sollten zusätzliche Netzwerk-Callbacks registrieren. Eine App, die für einen bestimmten Vorgang nur WLAN verwenden darf, ist beispielsweise eine App, die zusätzliche Netzwerke verwenden muss.

Obwohl das Standardnetzwerk für die meisten Apps das einzige relevante Netzwerk ist, sind einige Apps 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 Abhören eines Standardnetzwerks. Obwohl es zu einem bestimmten Zeitpunkt nur ein Standardnetzwerk für eine App geben kann, kann deine App in dieser Version 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 einen NetworkRequest, um ConnectivityManager darüber zu informieren, welche Art von Netzwerken sie überwachen möchte. Im folgenden Beispiel wird gezeigt, wie Sie eine NetworkRequest für eine App erstellen, die nur an Internetverbindungen ohne Datenlimit interessiert ist:

Kotlin

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

connectivityManager.registerNetworkCallback(request, myNetworkCallback)

Java

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 an Netzwerken ohne Datenlimit im System informiert wird.

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

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

Der Einfachheit halber enthält das Objekt NetworkRequest 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, ob die Standardeinstellungen Ihrem Anwendungsfall entsprechen, und löschen Sie sie, wenn Sie möchten, dass Ihre App über Netzwerke benachrichtigt wird, die diese Funktionen nicht haben. Andererseits sollten Sie Funktionen hinzufügen, um zu vermeiden, dass Sie bei jeder Verbindungsänderung in Netzwerken aufgerufen werden, mit denen Ihre App nicht interagiert.

Wenn Ihre App beispielsweise MMS-Nachrichten senden muss, fügen Sie NET_CAPABILITY_MMS zu NetworkRequest hinzu, damit Sie nicht über alle Netzwerke informiert werden, die keine MMS-Nachrichten senden können. Fügen Sie TRANSPORT_WIFI_AWARE hinzu, wenn Ihre App nur an einer P2P-WLAN-Verbindung 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 Abfolge 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 sie dann wieder. Im Beispiel wird außerdem davon ausgegangen, dass auf dem Gerät die Einstellung Mobile Daten immer aktiv aktiviert ist.

Der Zeitplan sieht folgendermaßen aus:

1. Wenn die App registerNetworkCallback() aufruft, empfängt 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: Anwendungsstatus 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 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 ohne Datenlimit her. Der reguläre Netzwerk-Callback empfängt Aufrufe an onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das WLAN.

   
   Abbildung 3: App-Status nach dem Herstellen einer Verbindung zu einem WLAN ohne Datenlimit.

4. Es kann einen Moment dauern, bis das WLAN validiert ist. 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 sie einen Aufruf von onNetworkCapabilitiesChanged(), wobei die neuen Funktionen NET_CAPABILITY_VALIDATED umfassen. In den meisten Fällen geht die Validierung sehr schnell.

   Wenn das WLAN-Netzwerk validiert wird, wird es vom System gegenüber dem Mobilfunknetz bevorzugt, hauptsächlich weil es ohne Datenlimit ist. Das WLAN wird zum Standardnetzwerk, sodass der Standardnetzwerk-Callback einen Aufruf von onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged() für das WLAN erhält. Das Mobilfunknetz wird in den Hintergrund verschoben und der reguläre Netzwerk-Callback empfängt einen Aufruf von onLosing() für das Mobilfunknetz.

   Da in diesem Beispiel davon ausgegangen wird, dass mobile Daten für dieses Gerät immer aktiviert sind, wird die Verbindung zum Mobilfunknetz nie getrennt. Wenn die Einstellung deaktiviert ist, wird die Verbindung zum Mobilfunknetz nach einer Weile getrennt und der reguläre Netzwerk-Callback erhält einen Aufruf 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 von onLost() für das 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 Verbindung zum WLAN.

Wenn die Einstellung Mobile Daten immer aktiv deaktiviert ist, versucht das Gerät, eine Verbindung zu einem Mobilfunknetz herzustellen, 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 auch Aufrufe an onAvailable(), onNetworkCapabilitiesChanged() und onLinkPropertiesChanged(), da das Mobilfunknetz verfügbar wird.

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

Wenn ein Netzwerk mit einem Netzwerk-Callback angezeigt wird, bedeutet das nicht, dass deine 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 Nutzung von Hintergrundnetzwerken unterliegt ebenfalls Berechtigungsprüfungen. Wenn deine App ein Hintergrundnetzwerk verwenden möchte, benötigt sie die Berechtigung CHANGE_NETWORK_STATE.

Apps mit dieser Berechtigung ermöglichen es dem System, 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.