Connectivity Manager: ano ito, mga pamamaraan at pagsubaybay sa koneksyon

Ano ang Connectivity Manager?

Ang ConnectivityManager — ay ang system service ng Android operating system, naa-access sa pamamagitan ng Context.getSystemService(Context.CONNECTIVITY_SERVICE). Nagbibigay ito ng API para sa pagkuha ng impormasyon tungkol sa network connection ng device, pagsubaybay sa mga pagbabago sa network at pamamahala ng mga network request ng application. Ang Connectivity Manager ay bahagi ng Android Framework mula noong unang bersyon ng platform (API Level 1) at sumailalim sa malalaking pagbabago sa paglipas ng mga dekada: mula sa simpleng getActiveNetworkInfo() hanggang sa modernong reactive model na may NetworkCallback at NetworkRequest.

Ang mga pangunahing kakayahan ng Connectivity Manager ay kinabibilangan ng: pagsusuri ng pagkakaroon ng aktibong network connection, pagtukoy ng uri ng network (Wi-Fi, mobile data, Ethernet, Bluetooth, VPN), real-time na pagsubaybay sa mga pagbabago sa network status, pagkuha ng impormasyon tungkol sa bandwidth at latency, pamamahala ng mga network request ng application. Ang ConnectivityManager ay ginagamit kasama ng WorkManager at Repository para i-implement ang Offline-First architecture, adaptive content loading at pag-optimize ng pagganap ng application batay sa kalidad ng koneksyon.

Mula noong Android 10 (API 29), binago ng Google ang approach sa pagtatrabaho sa ConnectivityManager. Ang pamamaraang getActiveNetworkInfo() ay idineklarang deprecated, at sa halip ay inirerekomenda ang paggamit ng registerDefaultNetworkCallback() o registerNetworkCallback() na may NetworkRequest. Ang bagong API ay nagbibigay ng mas detalyadong impormasyon tungkol sa network, kabilang ang kakayahang makita ang mga captive portal (Wi-Fi na may authentication) at suriin ang kalidad ng koneksyon. Ang ConnectivityManager ay integrated din sa Jetpack family: ang ConnectivityManager library ay inilabas noong 2024 bilang bahagi ng Jetpack para pasimplehin ang pagsubaybay sa network sa mga Compose application.

Role ng Connectivity Manager sa architecture ng application

Sa modernong Android architecture, ang Connectivity Manager ay ginagamit sa repository o UseCase level para gumawa ng mga desisyon tungkol sa mga network request. Ang Repository layer ay sumusuri sa network status bago tawagan ang API: kung hindi available ang network, ibinabalik ang data mula sa lokal na storage (Room). Kung available ang network, isinasagawa ang request sa server at ang resulta ay nai-save sa Room. Ang ViewModel ay nag-subscribe sa Flow mula sa Room at hindi alam ang mga detalye ng network interaction — ito ay nagpapahintulot ng madaling pag-test ng bawat layer nang nakapag-iisa.

Paano gumagana ang Connectivity Manager

Ang Connectivity Manager ay tumatanggap ng impormasyon tungkol sa network status mula sa system service na connectivity, na nakikipag-ugnayan sa mga network interface ng Linux kernel. Kapag ang device ay kumonekta sa Wi-Fi o nag-activate ng mobile data, ang kernel ay nag-aabiso sa system service, na nag-a-update ng internal na status at nag-aabiso sa lahat ng registered callbacks. Ang architecture ng ConnectivityManager ay binuo sa Observer pattern: ang application ay nagrerehistro ng NetworkCallback at tumatanggap ng mga notification tungkol sa anumang pagbabago sa network — paglitaw ng koneksyon, pagkawala nito, pagbabago ng uri ng network o pagbaba ng kalidad.

Ang modernong ConnectivityManager API ay gumagamit ng NetworkRequest para i-filter ang mga network event. Ang NetworkRequest ay nagpapahintulot na tukuyin ang mga kinakailangan para sa network: transport (Transport.WIFI, Transport.CELLULAR, Transport.ETHERNET), kakayahang ma-access ang internet (NetworkCapabilities.NET_CAPABILITY_INTERNET) at iba pang mga criteria. Kung ang application ay nangangailangan lamang ng Wi-Fi para mag-download ng malalaking file, gumagawa ito ng NetworkRequest na may Transport.WIFI at nagrerehistro ng callback. Ang system ay mag-aabiso lamang sa application kapag nagbago ang Wi-Fi connection, hindi pinapansin ang mga mobile network event.

Isang mahalagang feature ng Connectivity Manager sa Android 12+ ay ang capabilities-based networking. Ang application ay hindi lamang sumusuri kung may internet, kundi maaaring suriin kung anong uri ng trapiko ang available. Halimbawa, ang NET_CAPABILITY_NOT_METERED ay nagpapahiwatig ng unlimited na koneksyon (Wi-Fi), ang NET_CAPABILITY_NOT_ROAMING — na ang device ay hindi naka-roaming. Ito ay nagpapahintulot ng paggawa ng mga desisyon: mag-load ng video sa pamamagitan lamang ng Wi-Fi, ipagpaliban ang synchronization sa roaming, o gumamit ng mobile data lamang para sa mga kritikal na request.

Mga pahintulot para sa Connectivity Manager

Para magamit ang Connectivity Manager sa isang Android application, kinakailangan ang mga pahintulot. ACCESS_NETWORK_STATE — ang mandatoryong pahintulot para magbasa ng impormasyon tungkol sa network, na idineklara sa AndroidManifest.xml. Kung wala ang pahintulot na ito, ang ConnectivityManager ay magbabalik ng null para sa getActiveNetwork() at hindi tatawag ng mga callback. Para magsagawa ng mga network operation, kinakailangan din ang INTERNET permission. Mula noong Android 10 (API 29), ang application ay maaaring sumuri ng network status nang walang karagdagang runtime permissions — ang ACCESS_NETWORK_STATE ay isang normal permission at awtomatikong ibinibigay sa pag-install.

Mga pangunahing pamamaraan ng Connectivity Manager

Ang modernong Connectivity Manager ay nagbibigay ng ilang mahahalagang pamamaraan para sa pagtatrabaho sa network. Ang getActiveNetwork() (API 23+) ay nagbabalik ng Network object ng kasalukuyang aktibong network o null kung ang device ay hindi konektado. Ang pamamaraang ito ay hindi nangangailangan ng mga callback at angkop para sa isang beses na pagsusuri. Ang Network object ay maaaring ipasa sa NetworkCapabilities para makakuha ng detalyadong impormasyon: uri ng transport, metered status, roaming, kakayahang ma-access ang internet at iba pang mga katangian.

Ang registerDefaultNetworkCallback() (API 24+) — ang ginustong paraan ng pagsubaybay sa network. Ang application ay nagrerehistro ng callback na tinatawag sa anumang pagbabago sa default network (ang network kung saan ang application ay nagpapadala ng trapiko). Ang callback ay tumatanggap ng Network object na maaaring gamitin para mag-bind ng mga socket at HTTP clients. Ang pamamaraang ito ay pumapalit sa lumang getActiveNetworkInfo() at nagbibigay ng reactive network monitoring nang walang polling.

Ang registerNetworkCallback() (API 21+) ay nagpapahintulot na mag-subscribe sa mga pagbabago ng isang partikular na uri ng network sa pamamagitan ng NetworkRequest. Halimbawa, ang application ay maaaring sumubaybay lamang ng Wi-Fi networks sa pamamagitan ng new NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(). Ang system ay mag-aabiso sa application tungkol sa pagkonekta/pagdiskonekta mula sa Wi-Fi nang hindi naaapektuhan ang mobile network events. Ang NetworkCapabilities.getLinkDownstreamBandwidthKbps() ay nagbabalik ng tinantyang bandwidth ng downstream channel sa kbps, na nagpapahintulot na i-adapt ang kalidad ng nilalaman sa bilis ng koneksyon.

ConnectivityManager sa Jetpack Compose

Ang Jetpack Connectivity library (androidx.core:core-ktx) ay nagbibigay ng maginhawang mga extension para sa pagtatrabaho sa ConnectivityManager sa Compose. Ang function na ConnectivityManager.observeAsState() ay nagbabalik ng State<Boolean> na nag-a-update kapag nagbago ang network. Ang @Composable NetworkStatus() component ay nagpapakita ng connection status at awtomatikong nagre-redraw sa mga pagbabago. Ito ay nagpapalaya sa developer mula sa manual na pamamahala ng mga callback at lifecycle ng Activity/Fragment.

NetworkCallback at paghawak ng mga pagbabago sa network

Ang ConnectivityManager.NetworkCallback — ay isang abstract class na may mga pamamaraan na tinatawag ng system kapag nagbago ang network status. onAvailable(Network) — tinatawag kapag naging available ang network. Ang application ay tumatanggap ng Network object na maaaring gamitin para mag-bind ng mga socket sa pamamagitan ng Network.bindSocket(). onLost(Network) — tinatawag kapag naging unavailable ang network. Ang application ay dapat lumipat sa lokal na data o magpakita ng mensahe tungkol sa kawalan ng koneksyon. onCapabilitiesChanged(Network, NetworkCapabilities) — tinatawag kapag nagbago ang mga katangian ng network (halimbawa, kapag lumipat mula Wi-Fi patungong mobile data).

Ang tamang paghawak ng mga pagbabago sa network ay nangangailangan ng pagsasaalang-alang sa lifecycle ng component. Ang callback ay dapat na irehistro sa onStart()/onResume() at kanselahin sa onStop()/onPause(). Kung hindi nakansela ang callback, maaari itong tawagin pagkatapos masira ang Activity, na nagdudulot ng memory leak. Sa Jetpack ViewModel architecture, inirerekomenda ang paggamit ng lifecycleScope para irehistro ang callback upang awtomatiko itong makansela kapag na-clear ang ViewModel. Para sa mga serbisyo at background tasks, ginagamit ang WorkManager na may NetworkType restriction.

Paghawak ng mga captive portal — isang mahalagang kakayahan ng ConnectivityManager mula noong Android 10. CAPTIVE_PORTAL — senaryo kung saan available ang Wi-Fi network ngunit nangangailangan ng authentication sa pamamagitan ng web page (airports, hotels, cafe). Ang NetworkCapabilities.NET_CAPABILITY_VALIDATED ay nagpapahiwatig na ang network ay may ganap na access sa internet. Kung wala ang NET_CAPABILITY_VALIDATED, ang application ay maaaring magbukas ng browser para sa authentication sa pamamagitan ng captive portal. Para sa pag-detect ng captive portal, ginagamit ang isCaptivePortal() method, na idinagdag sa Android 11 (API 30).

Network para sa mga tiyak na layunin (NetworkRequest)

Ang ConnectivityManager ay nagpapahintulot na humiling ng network para sa mga tiyak na layunin sa pamamagitan ng requestNetwork() at bindProcessToNetwork(). Halimbawa, ang isang application para sa pag-download ng malalaking file ay maaaring humiling ng Wi-Fi network kahit na aktibo ang mobile network. Para dito, gumagawa ng NetworkRequest na may addTransportType(TRANSPORT_WIFI), at kapag lumitaw ang Wi-Fi, tinatawag ng system ang onAvailable(). Ang application ay nagba-bind ng mga socket sa network na ito sa pamamagitan ng network.bindSocket() o OkHttp na may naka-configure na Network object. Ito ay nagbibigay ng flexible na kontrol sa paggamit ng mga network interface.

Halimbawa ng implementasyon sa Kotlin

Tingnan natin ang isang kumpletong halimbawa ng paggamit ng ConnectivityManager na may modernong API (NetworkCallback) sa Clean Architecture. NetworkMonitor — isang wrapper class sa paligid ng ConnectivityManager na nagbibigay ng reactive network status sa pamamagitan ng StateFlow. Ang ViewModel ay nag-subscribe sa Flow na ito at nagpapadala ng status sa UI. Ang Repository ay gumagamit ng NetworkMonitor para gumawa ng mga desisyon tungkol sa mga network request. Ang approach na ito ay nagsisiguro ng testability at isolation ng platform dependencies.

Ang sumusunod na halimbawa ay nagpapakita kung paano gamitin nang tama ang ConnectivityManager na may registerDefaultNetworkCallback. Ang NetworkMonitor class ay nag-e-encapsulate ng trabaho sa system service at nagbibigay ng malinis na Kotlin Flow<Boolean>. Nagrerehistro ito ng callback sa pagsisimula at kinakansela ito sa pagtatapos ng lifecycle. Ang asynchronous na trabaho ay sinisiguro sa pamamagitan ng coroutines at callbackFlow — isang tulay sa pagitan ng callback style ng ConnectivityManager at ng reactive Flow style ng 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
        )
    }
}

Paggamit ng NetworkMonitor sa ViewModel at Repository

Ang ViewModel ay nag-subscribe sa NetworkMonitor.isOnline sa pamamagitan ng stateIn() at nagpapadala ng status sa Compose. Ang Repository ay sumusuri sa kasalukuyang halaga ng isOnline.value bago tawagan ang API: kung ito ay false — nagbabalik ng Flow mula sa Room. Kung ito ay true — tinatawag ang API, ini-save ang resulta sa Room at nagbabalik ng Flow mula sa Room. Ang WorkManager ay gumagamit ng NetworkType.CONNECTED para sa paglilimita ng background tasks. Ang pag-test ng NetworkMonitor ay ginagawa gamit ang mock ConnectivityManager object at fake NetworkCallback, na nagpapahintulot na i-emulate ang anumang network scenario sa unit tests.

Best Practices at mga karaniwang pagkakamali

Unang panuntunan sa pagtatrabaho sa ConnectivityManager — huwag gumamit ng lumang API. Ang getActiveNetworkInfo() ay deprecated mula noong API 29 at maaaring magbalik ng hindi tamang data sa mga bagong bersyon ng Android. Sa halip, gamitin ang getActiveNetwork() + getNetworkCapabilities() para sa isang beses na pagsusuri at registerDefaultNetworkCallback() para sa tuloy-tuloy na pagsubaybay. Ang lumang pamamaraan ay hindi nagkakaintindi ng pagkakaiba sa pagitan ng network na may captive portal at ng buong internet, na nagdudulot ng false positive na resulta.

Ikalawang panuntunan — laging kanselahin ang pagrehistro ng callback. Kung ang Activity ay nagrerehistro ng NetworkCallback sa onStart() ngunit hindi kinakansela sa onStop(), ang callback ay patuloy na gagana pagkatapos masira ang Activity. Ito ay nagdudulot ng memory leak at potensyal na NullPointerException kapag sinubukan ng callback na i-update ang UI ng nasirang component. Gamitin ang lifecycleScope o repeatOnLifecycle para sa awtomatikong pamamahala ng pagrehistro. Sa Jetpack Compose, gamitin ang DisposableEffect para sa pagrehistro at pagkansela ng callback.

Ikatlong karaniwang pagkakamali — pagsusuri lamang ng pagkakaroon ng network nang hindi isinasaalang-alang ang kalidad nito. Simpleng "may internet" ay hindi sapat para sa paggawa ng desisyon. Ang application ay dapat sumuri ng NET_CAPABILITY_NOT_METERED para sa pag-download ng malalaking file, NET_CAPABILITY_NOT_ROAMING para sa background synchronization, NET_CAPABILITY_VALIDATED para sa kumpirmasyon ng internet access. Ang pag-walang-bahala sa mga flag na ito ay nagdudulot na subukan ng application na mag-load ng video sa roaming o mag-sync ng data sa pamamagitan ng captive portal ng hotel.

Ikaapat — huwag gamitin ang ConnectivityManager para suriin ang availability ng isang partikular na server. Ang ConnectivityManager ay nag-uulat ng network status sa device, ngunit hindi ginagarantiyahan na ang server ay available. Para suriin ang availability ng API, gumamit ng HTTP request na may maikling timeout o Health Check. Ang ConnectivityManager + HTTP ping ay isang maaasahang kombinasyon: unang sinusuri ang pagkakaroon ng network, pagkatapos ay nagpapadala ng magaan na request sa server para kumpirmahin ang aktwal na availability.

Pag-test ng ConnectivityManager

Para sa unit tests, gamitin ang Robolectric na may ShadowConnectivityManager, na nagpapahintulot na i-emulate ang network status. Para sa integration tests — Android Test Orchestrator na may pagpapalit ng Airplane Mode. Sa mga test, suriin ang mga scenario: paglipat mula online patungong offline, paglitaw ng Wi-Fi habang aktibo ang mobile network, pagkawala ng network habang isinasagawa ang request, captive portal, roaming. Para sa mocking sa modular tests, gumamit ng wrapper interface (hal. NetworkMonitorInterface) na maaaring palitan ng mock object nang walang platform dependencies.