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() оголошено застарілим, і замість нього рекомендується використовувати registerDefaultNetworkCallback() або registerNetworkCallback() з NetworkRequest. Новий API надає більш детальну інформацію про мережу, включаючи можливість виявлення каптивних порталів (Wi-Fi з автентифікацією) та оцінки якості з’єднання. ConnectivityManager також інтегрований з родиною Jetpack: бібліотека ConnectivityManager вийшла у 2024 році як частина Jetpack для спрощення моніторингу мережі в Compose-додатках.

Роль Connectivity Manager в архітектурі додатка

У сучасній Android-архітектурі Connectivity Manager використовується на рівні репозиторію або UseCase для прийняття рішень про мережеві запити. Repository Layer перевіряє стан мережі перед викликом 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), додаток може перевіряти стан мережі без додаткових дозволів часу виконання — ACCESS_NETWORK_STATE є нормальним дозволом і надається автоматично при встановленні додатка.

Основні методи Connectivity Manager

Сучасний Connectivity Manager надає кілька ключових методів для роботи з мережею. getActiveNetwork() (API 23+) повертає Network-об’єкт поточної активної мережі або null, якщо пристрій не підключений. Цей метод не потребує колбеків та підходить для одноразової перевірки. Network-об’єкт можна передати в NetworkCapabilities для отримання детальної інформації: тип транспорту, метеризований статус, роумінг, можливість виходу в інтернет та інші характеристики.

registerDefaultNetworkCallback() (API 24+) — найкращий спосіб моніторингу мережі. Додаток реєструє колбек, який викликається при будь-яких змінах мережі за замовчуванням (мережі, через яку додаток відправляє трафік). Колбек отримує Network-об’єкт, який можна використовувати для зв’язування сокетів та HTTP-клієнтів. Цей метод замінює застарілий getActiveNetworkInfo() та забезпечує реактивний моніторинг мережі без поллінгу.

registerNetworkCallback() (API 21+) дозволяє підписатися на зміни певного типу мережі через NetworkRequest. Наприклад, додаток може відстежувати лише Wi-Fi-мережі через new NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(). Система сповіщатиме додаток про підключення/відключення Wi-Fi, не зачіпаючи події мобільної мережі. NetworkCapabilities.getLinkDownstreamBandwidthKbps() повертає оцінку пропускної здатності низхідного каналу в кбіт/с, що дозволяє адаптувати якість контенту під швидкість з’єднання.

ConnectivityManager в Jetpack Compose

Бібліотека Jetpack Connectivity (androidx.core:core-ktx) надає зручні розширення для роботи з ConnectivityManager в Compose. Функція ConnectivityManager.observeAsState() повертає State, який оновлюється при зміні мережі. Компонент @Composable NetworkStatus() відображає статус підключення та автоматично перемалювується при змінах. Це позбавляє розробника від ручного керування колбеками та життєвим циклом Activity/Fragment.

NetworkCallback та обробка змін мережі

ConnectivityManager.NetworkCallback — це абстрактний клас з методами, які викликаються системою при зміні стану мережі. onAvailable(Network) — викликається, коли мережа стає доступною. Додаток отримує Network-об’єкт, який можна використовувати для зв’язування сокетів через Network.bindSocket(). onLost(Network) — викликається, коли мережа стає недоступною. Додаток повинен перейти на локальні дані або показати повідомлення про відсутність з’єднання. onCapabilitiesChanged(Network, NetworkCapabilities) — викликається при зміні характеристик мережі (наприклад, при перемиканні з Wi-Fi на мобільні дані).

Правильна обробка змін мережі потребує врахування життєвого циклу компонента. Колбек повинен бути зареєстрований в onStart()/onResume() та відмінений в onStop()/onPause(). Якщо колбек не відмінено, він може викликатися після знищення Activity, що призведе до витоку пам’яті та потенційного NullPointerException, коли колбек намагається оновити UI знищеного компонента. Використовуйте lifecycleScope або repeatOnLifecycle для автоматичного керування реєстрацією. В Jetpack Compose використовуйте DisposableEffect для реєстрації та відміни колбека.

Обробка каптивних порталів — важлива можливість 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. Він реєструє колбек при старті та відміняє його при завершенні життєвого циклу. Асинхронна робота забезпечується через корутини та 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 з перемиканням Airplane Mode. В тестах перевіряйте сценарії: перехід з онлайн в офлайн, поява Wi-Fi при активній мобільній мережі, втрата мережі під час виконання запиту, каптивний портал, роумінг. Для mocking в модульних тестах використовуйте інтерфейс-обгортку (наприклад, NetworkMonitorInterface), який можна замінити mock-об'єктом без платформених залежностей.