Connectivity Manager: шта је то, методе и надгледање повезивања

Шта је Connectivity Manager?

ConnectivityManager — системски сервис оперативног система Android, доступан преко Context.getSystemService(Context.CONNECTIVITY_SERVICE). Пружа API за добијање информација о мрежном повезивању уређаја, надгледање промена мреже и управљање мрежним захтевима апликације. Connectivity Manager је део Android Framework-а од прве верзије платформе (API Level 1) и током деценија је претрпео значајне промене: од једноставног getActiveNetworkInfo() до модерног реактивног модела са NetworkCallback и NetworkRequest.

Главне могућности Connectivity Manager-а укључују: проверу постојања активног мрежног повезивања, одређивање типа мреже (Wi-Fi, мобилни подаци, Ethernet, Bluetooth, VPN), праћење промена стања мреже у реалном времену, добијање информација о пропусном опсегу и кашњењима, управљање мрежним захтевима апликације. ConnectivityManager се користи заједно са WorkManager-ом и Repository-јем за имплементацију Offline-First архитектуре, адаптивног учитавања садржаја и оптимизације рада апликације у зависности од квалитета везе.

Почев од Android 10 (API 29), Google је променио приступ раду са ConnectivityManager-ом. Метода getActiveNetworkInfo() је проглашена deprecated, а уместо ње се препоручује коришћење registerDefaultNetworkCallback() или registerNetworkCallback() са NetworkRequest-ом. Нови API пружа детаљније информације о мрежи, укључујући могућност откривања каптивних портала (Wi-Fi са ауторизацијом) и процену квалитета везе. ConnectivityManager је такође интегрисан са Jetpack породицом: библиотека ConnectivityManager је објављена 2024. године као део Jetpack-а за поједностављење надгледања мреже у Compose апликацијама.

Улога Connectivity Manager-а у архитектури апликације

У модерној Android архитектури, Connectivity Manager се користи на нивоу repository-ја или UseCase-а за доношење одлука о мрежним захтевима. Repository слој проверава стање мреже пре позивања API-ја: ако је мрежа недоступна, враћају се подаци из локалног складишта (Room). Ако је мрежа доступна, извршава се захтев ка серверу, а резултат се чува у Room-у. ViewModel се претплаћује на Flow из Room-а и не зна детаље мрежне интеракције — то омогућава лако тестирање сваког слоја независно.

Како функционише Connectivity Manager

Connectivity Manager добија информације о мрежном стању од системског сервиса connectivity, који комуницира са мрежним интерфејсима Linux кернела. Када се уређај повеже на Wi-Fi или укључи мобилне податке, кернел обавештава системски сервис, који ажурира унутрашње стање и обавештава све регистроване колбекове. Архитектура ConnectivityManager-а је изграђена на Observer обрасцу: апликација региструје NetworkCallback и добија обавештења о било каквим променама мреже — појави везе, њеном губитку, промени типа мреже или погоршању квалитета.

Модерни API ConnectivityManager-а користи NetworkRequest за филтрирање мрежних догађаја. NetworkRequest омогућава одређивање захтева за мрежу: транспорт (Transport.WIFI, Transport.CELLULAR, Transport.ETHERNET), могућност изласка на интернет (NetworkCapabilities.NET_CAPABILITY_INTERNET) и друге критеријуме. Ако апликацији треба само Wi-Fi за преузимање великих датотека, креира NetworkRequest са Transport.WIFI и региструје колбек. Систем ће обавестити апликацију само при промени Wi-Fi везе, игноришући догађаје мобилне мреже.

Важна карактеристика Connectivity Manager-а на Android 12+ — capabilities-based networking. Апликација не само да проверава „да ли има интернета", већ може проценити који тип саобраћаја је доступан. На пример, NET_CAPABILITY_NOT_METERED указује на неограничену везу (Wi-Fi), NET_CAPABILITY_NOT_ROAMING — да уређај није у роумингу. То омогућава доношење одлука: учитавати видео само преко Wi-Fi-ја, одлагати синхронизацију у роумингу или користити мобилне податке само за критичне захтеве.

Дозволе за Connectivity Manager

За коришћење Connectivity Manager-а у Android апликацији потребне су дозволе. ACCESS_NETWORK_STATE — обавезна дозвола за читање информација о мрежи, декларише се у AndroidManifest.xml. Без ове дозволе ConnectivityManager ће вратити null за getActiveNetwork() и неће позивати колбекове. За извршавање мрежних операција такође је потребна INTERNET дозвола. Почев од Android 10 (API 29), апликација може проверавати стање мреже без додатних runtime дозвола — ACCESS_NETWORK_STATE је нормална дозвола (normal permission) и додељује се аутоматски при инсталацији.

Главне методе Connectivity Manager-а

Модерни Connectivity Manager пружа неколико кључних метода за рад са мрежом. getActiveNetwork() (API 23+) враћа Network објекат тренутне активне мреже или null ако уређај није повезан. Ова метода не захтева колбекове и погодна је за једнократну проверу. Network објекат се може проследити у NetworkCapabilities за добијање детаљних информација: тип транспорта, metered статус, роаминг, могућност изласка на интернет и друге карактеристике.

registerDefaultNetworkCallback() (API 24+) — пожељан начин надгледања мреже. Апликација региструје колбек који се позива при било каквим променама подразумеване мреже (мреже кроз коју апликација шаље саобраћај). Колбек добија Network објекат који се може користити за повезивање сокета и HTTP клијената. Ова метода замењује застарели getActiveNetworkInfo() и обезбеђује реактивно надгледање мреже без полинга.

registerNetworkCallback() (API 21+) омогућава претплату на промене одређеног типа мреже кроз NetworkRequest. На пример, апликација може пратити само Wi-Fi мреже кроз new NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(). Систем ће обавештавати апликацију о повезивању/искључивању са Wi-Fi-ја, не утичући на догађаје мобилне мреже. NetworkCapabilities.getLinkDownstreamBandwidthKbps() враћа процену пропусног опсега низводног канала у kbps, што омогућава прилагођавање квалитета садржаја брзини везе.

ConnectivityManager у Jetpack Compose-у

Библиотека Jetpack Connectivity (androidx.core:core-ktx) пружа згодна проширења за рад са ConnectivityManager-ом у Compose-у. Функција ConnectivityManager.observeAsState() враћа State<Boolean> који се ажурира при промени мреже. Компонента @Composable NetworkStatus() приказује статус повезивања и аутоматски се прецртава при променама. То ослобађа програмера од ручног управљања колбековима и животним циклусом Activity/Fragment-а.

NetworkCallback и обрада промена мреже

ConnectivityManager.NetworkCallback — апстрактна класа са методама које систем позива при промени стања мреже. onAvailable(Network) — позива се када мрежа постане доступна. Апликација добија Network објекат који се може користити за повезивање сокета кроз Network.bindSocket(). onLost(Network) — позива се када мрежа постане недоступна. Апликација треба да се пребаци на локалне податке или прикаже поруку о недостатку везе. onCapabilitiesChanged(Network, NetworkCapabilities) — позива се при промени карактеристика мреже (на пример, при преласку са Wi-Fi-ја на мобилне податке).

Правилна обрада промена мреже захтева узимање у обзир животног циклуса компоненте. Колбек треба да буде регистрован у onStart()/onResume() и отказан у onStop()/onPause(). Ако колбек није отказан, може се позивати након уништења Activity-ја, што доводи до цурења меморије. У Jetpack ViewModel архитектури препоручује се коришћење lifecycleScope-а за регистрацију колбека како би се аутоматски отказао при чишћењу ViewModel-а. За сервисе и позадинске задатке користи се WorkManager са NetworkType ограничењем.

Обрада каптивних портала — важна могућност ConnectivityManager-а почев од Android 10. CAPTIVE_PORTAL — сценарио када је Wi-Fi мрежа доступна, али захтева ауторизацију кроз веб страницу (аеродроми, хотели, кафићи). NetworkCapabilities.NET_CAPABILITY_VALIDATED указује да мрежа има пун приступ интернету. Ако NET_CAPABILITY_VALIDATED недостаје, апликација може отворити прегледач за ауторизацију кроз каптивни портал. За откривање каптивног портала користи се метода isCaptivePortal(), додата у Android 11 (API 30).

Мрежа за специфичне намене (NetworkRequest)

ConnectivityManager омогућава захтевање мреже за конкретне намене кроз requestNetwork() и bindProcessToNetwork(). На пример, апликација за преузимање великих датотека може захтевати Wi-Fi мрежу чак и ако је активна мобилна. За то се креира NetworkRequest са addTransportType(TRANSPORT_WIFI), а када се Wi-Fi појави, систем позива onAvailable(). Апликација повезује сокете са овом мрежом кроз network.bindSocket() или OkHttp са конфигурисаним Network објектом. То пружа флексибилну контролу над коришћењем мрежних интерфејса.

Пример имплементације у Kotlin-у

Размотримо комплетан пример коришћења ConnectivityManager-а са модерним API-јем (NetworkCallback) у Clean Architecture. NetworkMonitor — класа-омотач око ConnectivityManager-а која пружа реактивни статус мреже кроз StateFlow. ViewModel се претплаћује на овај Flow и преноси стање у UI. Repository користи NetworkMonitor за доношење одлука о мрежним захтевима. Овај приступ обезбеђује тестирабилност и изолацију платформских зависности.

Пример испод показује како правилно користити ConnectivityManager са registerDefaultNetworkCallback. Класа NetworkMonitor инкапсулира рад са системским сервисом и пружа чист Kotlin Flow<Boolean>. Региструје колбек при покретању и отказује га при завршетку животног циклуса. Асинхрони рад је обезбеђен кроз корутине и callbackFlow — мост између колбек стила ConnectivityManager-а и реактивног Flow стила Kotlin-а.

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

Коришћење NetworkMonitor-а у ViewModel-у и Repository-ју

ViewModel се претплаћује на NetworkMonitor.isOnline кроз stateIn() и преноси стање у Compose. Repository проверава тренутну вредност isOnline.value пре позивања API-ја: ако је false — враћа Flow из Room-а. Ако је true — позива API, чува резултат у Room-у и враћа Flow из Room-а. WorkManager користи NetworkType.CONNECTED за ограничавање позадинских задатака. Тестирање NetworkMonitor-а се врши са mock ConnectivityManager објектом и fake NetworkCallback-ом, што омогућава емулацију било којих мрежних сценарија у јединичним тестовима.

Best Practices и честе грешке

Прво правило рада са ConnectivityManager-ом — не користити застарели API. getActiveNetworkInfo() је deprecated од API 29 и може враћати нетачне податке на новим верзијама Android-а. Уместо њега користите getActiveNetwork() + getNetworkCapabilities() за једнократну проверу и registerDefaultNetworkCallback() за непрекидно надгледање. Стара метода не разликује мреже са каптивним порталом и комплетним интернетом, што доводи до лажних резултата.

Друго правило — увек отказати регистрацију колбека. Ако Activity региструје NetworkCallback у onStart(), али га не откаже у onStop(), колбек наставља да ради након уништења Activity-ја. То изазива цурење меморије и потенцијални NullPointerException када колбек покуша да ажурира UI уништене компоненте. Користите lifecycleScope или repeatOnLifecycle за аутоматско управљање регистрацијом. У Jetpack Compose-у користите DisposableEffect за регистрацију и отказивање колбека.

Трећа честа грешка — провера само постојања мреже без узимања у обзир њеног квалитета. Једноставно „има интернета" није довољно за доношење одлука. Апликација треба да проверава NET_CAPABILITY_NOT_METERED за преузимање великих датотека, NET_CAPABILITY_NOT_ROAMING за синхронизацију у позадини, NET_CAPABILITY_VALIDATED за потврду изласка на интернет. Игнорисање ових заставица доводи до тога да апликација покушава да учитава видео у роумингу или синхронизује податке кроз каптивни портал хотела.

Четврто — не користити ConnectivityManager за проверу доступности одређеног сервера. ConnectivityManager извештава о стању мреже на уређају, али не гарантује да је сервер доступан. За проверу доступности API-ја користите HTTP захтев са кратким тајм-аутом или Health Check. ConnectivityManager + HTTP ping је поуздана комбинација: прво се проверава постојање мреже, затим се извршава лагани захтев ка серверу за потврду стварне доступности.

Тестирање ConnectivityManager-а

За јединичне тестове користите Robolectric са ShadowConnectivityManager-ом, који омогућава емулацију стања мреже. За интеграционе тестове — Android Test Orchestrator са пребацивањем Авион режима. У тестовима проверавајте сценарије: прелазак из онлајн у офлајн, појаву Wi-Fi-ја при активној мобилној мрежи, губитак мреже током извршавања захтева, каптивни портал, роаминг. За mocking у модуларним тестовима користите интерфејс-омотач (нпр. NetworkMonitorInterface) који се може заменити mock објектом без платформских зависности.