Connectivity Manager: vad är det, metoder och övervakning av anslutning

Vad är Connectivity Manager?

ConnectivityManager — är systemtjänsten i Android-operativsystemet, tillgänglig via Context.getSystemService(Context.CONNECTIVITY_SERVICE). Den tillhandahåller ett API för att få information om enhetens nätverksanslutning, övervaka nätverksändringar och hantera applikationens nätverksförfrågningar. ConnectivityManager har varit en del av Android Framework sedan den första versionen av plattformen (API Level 1) och har genomgått betydande förändringar under decennierna: från enkel getActiveNetworkInfo() till den moderna reaktiva modellen med NetworkCallback och NetworkRequest.

De huvudsakliga möjligheterna med Connectivity Manager inkluderar: kontroll av aktiv nätverksanslutning, bestämning av nätverkstyp (Wi-Fi, mobildata, Ethernet, Bluetooth, VPN), realtidsövervakning av nätverksstatusförändringar, hämtning av information om bandbredd och fördröjning, hantering av applikationens nätverksförfrågningar. ConnectivityManager används tillsammans med WorkManager och Repository för att implementera Offline-First-arkitektur, adaptiv inläsning av innehåll och optimering av applikationens funktion baserat på anslutningskvalitet.

Från och med Android 10 (API 29) ändrade Google sitt förhållningssätt till att arbeta med ConnectivityManager. Metoden getActiveNetworkInfo() har förklarats deprecated och istället rekommenderas att använda registerDefaultNetworkCallback() eller registerNetworkCallback() med NetworkRequest. Det nya API:t ger mer detaljerad information om nätverket, inklusive möjlighet att upptäcka captive-portaler (Wi-Fi med autentisering) och bedöma anslutningskvalitet. ConnectivityManager är också integrerat med Jetpack-familjen: ConnectivityManager-biblioteket lanserades 2024 som en del av Jetpack för att förenkla nätverksövervakning i Compose-applikationer.

Connectivity Managers roll i applikationsarkitekturen

I modern Android-arkitektur används Connectivity Manager på repository- eller UseCase-nivå för att fatta beslut om nätverksförfrågningar. Repository-lagret kontrollerar nätverkets status innan API-anropet: om nätverket är otillgängligt returneras data från lokal lagring (Room). Om nätverket är tillgängligt utförs en förfrågan till servern och resultatet sparas i Room. ViewModel prenumererar på Flow från Room och känner inte till detaljerna i nätverksinteraktionen — detta gör det möjligt att enkelt testa varje lager oberoende.

Hur fungerar Connectivity Manager

Connectivity Manager får information om nätverksstatus från systemtjänsten connectivity, som kommunicerar med Linux-kärnans nätverksgränssnitt. När enheten ansluter till Wi-Fi eller aktiverar mobildata meddelar kärnan systemtjänsten, som uppdaterar den interna statusen och meddelar alla registrerade callbacks. Arkitekturen för ConnectivityManager är byggd på Observer-mönstret: applikationen registrerar NetworkCallback och får meddelanden om alla nätverksförändringar — uppkomst av anslutning, dess förlust, ändring av nätverkstyp eller försämrad kvalitet.

Den moderna ConnectivityManager API använder NetworkRequest för att filtrera nätverkshändelser. NetworkRequest gör det möjligt att specificera krav på nätverket: transport (Transport.WIFI, Transport.CELLULAR, Transport.ETHERNET), möjlighet till internetåtkomst (NetworkCapabilities.NET_CAPABILITY_INTERNET) och andra kriterier. Om en applikation endast behöver Wi-Fi för att ladda ner stora filer skapar den en NetworkRequest med Transport.WIFI och registrerar en callback. Systemet meddelar applikationen endast vid ändring av Wi-Fi-anslutningen och ignorerar mobilnätshändelser.

En viktig egenskap hos Connectivity Manager på Android 12+ är capabilities-based networking. Applikationen kontrollerar inte bara "om det finns internet" utan kan bedöma vilken typ av trafik som är tillgänglig. NET_CAPABILITY_NOT_METERED indikerar till exempel en obegränsad anslutning (Wi-Fi), NET_CAPABILITY_NOT_ROAMING — att enheten inte är i roaming. Detta gör det möjligt att fatta beslut: ladda video endast via Wi-Fi, skjuta upp synkronisering i roaming eller använda mobildata endast för kritiska förfrågningar.

Behörigheter för Connectivity Manager

För att använda Connectivity Manager i en Android-app krävs behörigheter. ACCESS_NETWORK_STATE — den obligatoriska behörigheten för att läsa nätverksinformation, deklareras i AndroidManifest.xml. Utan denna behörighet returnerar ConnectivityManager null för getActiveNetwork() och anropar inte callbacks. För att utföra nätverksoperationer krävs även INTERNET-behörigheten. Från och med Android 10 (API 29) kan applikationen kontrollera nätverksstatus utan ytterligare runtime-behörigheter — ACCESS_NETWORK_STATE är en normal behörighet (normal permission) och ges automatiskt vid installation.

Huvudmetoder i Connectivity Manager

Den moderna Connectivity Manager erbjuder flera viktiga metoder för att arbeta med nätverket. getActiveNetwork() (API 23+) returnerar Network-objektet för det aktuella aktiva nätverket eller null om enheten inte är ansluten. Denna metod kräver inga callbacks och är lämplig för engångskontroll. Network-objektet kan skickas till NetworkCapabilities för att få detaljerad information: transporttyp, metered-status, roaming, internetåtkomst och andra egenskaper.

registerDefaultNetworkCallback() (API 24+) — det föredragna sättet att övervaka nätverket. Applikationen registrerar en callback som anropas vid alla ändringar av standardnätverket (nätverket som applikationen skickar trafik genom). Callbacken får ett Network-objekt som kan användas för att binda sockets och HTTP-klienter. Denna metod ersätter den föråldrade getActiveNetworkInfo() och ger reaktiv nätverksövervakning utan polling.

registerNetworkCallback() (API 21+) gör det möjligt att prenumerera på ändringar av en specifik nätverkstyp via NetworkRequest. Till exempel kan en applikation endast övervaka Wi-Fi-nätverk via new NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(). Systemet meddelar applikationen om anslutning/frånkoppling från Wi-Fi utan att påverka mobilnätshändelser. NetworkCapabilities.getLinkDownstreamBandwidthKbps() returnerar den uppskattade bandbredden för nedströmskanalen i kbps, vilket gör det möjligt att anpassa innehållskvaliteten till anslutningshastigheten.

ConnectivityManager i Jetpack Compose

Biblioteket Jetpack Connectivity (androidx.core:core-ktx) erbjuder praktiska tillägg för att arbeta med ConnectivityManager i Compose. Funktionen ConnectivityManager.observeAsState() returnerar State<Boolean> som uppdateras vid nätverksändringar. Komponenten @Composable NetworkStatus() visar anslutningsstatus och ritas automatiskt om vid ändringar. Detta befriar utvecklaren från manuell hantering av callbacks och Activity/Fragmentets livscykel.

NetworkCallback och hantering av nätverksändringar

ConnectivityManager.NetworkCallback — är en abstrakt klass med metoder som systemet anropar vid ändring av nätverksstatus. onAvailable(Network) — anropas när nätverket blir tillgängligt. Applikationen får ett Network-objekt som kan användas för att binda sockets via Network.bindSocket(). onLost(Network) — anropas när nätverket blir otillgängligt. Applikationen bör växla till lokala data eller visa ett meddelande om att anslutningen saknas. onCapabilitiesChanged(Network, NetworkCapabilities) — anropas vid ändring av nätverksegenskaper (till exempel vid växling från Wi-Fi till mobildata).

Korrekt hantering av nätverksändringar kräver hänsyn till komponentens livscykel. Callbacken bör registreras i onStart()/onResume() och avregistreras i onStop()/onPause(). Om callbacken inte avregistreras kan den anropas efter att Activity förstörts, vilket leder till minnesläckor. I Jetpack ViewModel-arkitektur rekommenderas att använda lifecycleScope för att registrera callbacken så att den automatiskt avregistreras vid rensning av ViewModel. För tjänster och bakgrundsuppgifter används WorkManager med NetworkType-begränsning.

Hantering av captive-portaler — en viktig funktion hos ConnectivityManager från och med Android 10. CAPTIVE_PORTAL — ett scenario där Wi-Fi-nätverket är tillgängligt men kräver autentisering via en webbsida (flygplatser, hotell, kaféer). NetworkCapabilities.NET_CAPABILITY_VALIDATED indikerar att nätverket har full internetåtkomst. Om NET_CAPABILITY_VALIDATED saknas kan applikationen öppna webbläsaren för autentisering via captive-portalen. För att upptäcka en captive-portal används metoden isCaptivePortal(), som lades till i Android 11 (API 30).

Nätverk för specifika ändamål (NetworkRequest)

ConnectivityManager gör det möjligt att begära ett nätverk för specifika ändamål via requestNetwork() och bindProcessToNetwork(). Till exempel kan en applikation för nedladdning av stora filer begära ett Wi-Fi-nätverk även om mobilnätet är aktivt. För detta skapas en NetworkRequest med addTransportType(TRANSPORT_WIFI), och när Wi-Fi dyker upp anropar systemet onAvailable(). Applikationen binder sockets till detta nätverk via network.bindSocket() eller OkHttp med ett konfigurerat Network-objekt. Detta ger flexibel kontroll över användningen av nätverksgränssnitt.

Exempel på implementering i Kotlin

Låt oss titta på ett komplett exempel på användning av ConnectivityManager med modern API (NetworkCallback) i Clean Architecture. NetworkMonitor — en wrapper-klass runt ConnectivityManager som ger reaktiv nätverksstatus via StateFlow. ViewModel prenumererar på denna Flow och skickar status till UI:t. Repository använder NetworkMonitor för att fatta beslut om nätverksförfrågningar. Detta tillvägagångssätt säkerställer testbarhet och isolering av plattformsberoenden.

Exemplet nedan visar hur man korrekt använder ConnectivityManager med registerDefaultNetworkCallback. Klassen NetworkMonitor kapslar in arbetet med systemtjänsten och tillhandahåller en ren Kotlin Flow<Boolean>. Den registrerar callbacken vid start och avregistrerar den vid livscykelns slut. Asynkront arbete säkerställs genom coroutines och callbackFlow — en bro mellan ConnectivityManagers callback-stil och Kotlins reaktiva Flow-stil.

class NetworkMonitor(
    private val connectivityManager: ConnectivityManager
) {
    val isOnline: StateFlow<Boolean> = callbackFlow {
        val callback = object : ConnectivityManager.NetworkCallback() {
            override fun onAvailable(network: Network) {
                trySend(true)
            }
            override fun onLost(network: Network) {
                trySend(false)
            }
            override fun onCapabilitiesChanged(
                network: Network,
                caps: NetworkCapabilities
            ) {
                val connected = caps.hasCapability(
                    NetworkCapabilities.NET_CAPABILITY_INTERNET
                )
                trySend(connected)
            }
        }
        connectivityManager.registerDefaultNetworkCallback(callback)
        awaitClose {
            connectivityManager.unregisterNetworkCallback(callback)
        }
    }.stateIn(
        CoroutineScope(Dispatchers.Default),
        SharingStarted.WhileSubscribed(5000),
        initialValue = checkInitialState()
    )

    private fun checkInitialState(): Boolean {
        val network = connectivityManager.getActiveNetwork() ?: return false
        val caps = connectivityManager.getNetworkCapabilities(network) ?: return false
        return caps.hasCapability(
            NetworkCapabilities.NET_CAPABILITY_INTERNET
        )
    }
}

Användning av NetworkMonitor i ViewModel och Repository

ViewModel prenumererar på NetworkMonitor.isOnline via stateIn() och skickar status till Compose. Repository kontrollerar det aktuella värdet av isOnline.value innan API-anropet: om det är false — returneras Flow från Room. Om det är true — anropas API:t, resultatet sparas i Room och Flow returneras från Room. WorkManager använder NetworkType.CONNECTED för att begränsa bakgrundsuppgifter. Testning av NetworkMonitor görs med ett mock-objekt för ConnectivityManager och fake NetworkCallback, vilket gör det möjligt att emulera alla nätverksscenarier i enhetstester.

Best Practices och vanliga misstag

Första regeln vid arbete med ConnectivityManager — använd inte föråldrat API. getActiveNetworkInfo() är deprecated från API 29 och kan returnera felaktiga data på nya Android-versioner. Använd istället getActiveNetwork() + getNetworkCapabilities() för engångskontroll och registerDefaultNetworkCallback() för kontinuerlig övervakning. Den gamla metoden skiljer inte mellan nätverk med captive-portal och fullt internet, vilket leder till falska positiva resultat.

Andra regeln — avregistrera alltid callbacken. Om Activity registrerar NetworkCallback i onStart() men inte avregistrerar i onStop(), fortsätter callbacken att fungera efter att Activity förstörts. Detta orsakar minnesläckor och potentiell NullPointerException när callbacken försöker uppdatera UI:t för den förstörda komponenten. Använd lifecycleScope eller repeatOnLifecycle för automatisk registreringshantering. I Jetpack Compose, använd DisposableEffect för att registrera och avregistrera callbacken.

Tredje vanliga misstaget — att endast kontrollera om nätverket finns utan att ta hänsyn till dess kvalitet. Enbart "det finns internet" är inte tillräckligt för beslutsfattande. Applikationen bör kontrollera NET_CAPABILITY_NOT_METERED för nedladdning av stora filer, NET_CAPABILITY_NOT_ROAMING för bakgrundssynkronisering, NET_CAPABILITY_VALIDATED för bekräftelse av internetåtkomst. Att ignorera dessa flaggor leder till att applikationen försöker ladda video i roaming eller synkronisera data via hotellets captive-portal.

Fjärde — använd inte ConnectivityManager för att kontrollera tillgängligheten av en specifik server. ConnectivityManager rapporterar nätverksstatus på enheten men garanterar inte att servern är tillgänglig. För att kontrollera API-tillgänglighet, använd en HTTP-förfrågan med kort timeout eller Health Check. ConnectivityManager + HTTP-ping är en pålitlig kombination: först kontrolleras nätverkets existens, sedan skickas en lätt förfrågan till servern för att bekräfta faktisk tillgänglighet.

Testning av ConnectivityManager

För enhetstester, använd Robolectric med ShadowConnectivityManager, som gör det möjligt att emulera nätverksstatus. För integrationstester — Android Test Orchestrator med växling av flygplansläge. I tester, kontrollera scenarier: övergång från online till offline, uppkomst av Wi-Fi när mobilnätet är aktivt, förlust av nätverk under en förfrågan, captive-portal, roaming. För mockning i modulära tester, använd ett wrapper-gränssnitt (t.ex. NetworkMonitorInterface) som kan ersättas med ett mock-objekt utan plattformsberoenden.