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 используется на уровне репозитория или 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), приложение может проверять состояние сети без дополнительных runtime-разрешений — ACCESS_NETWORK_STATE является нормальным (normal) разрешением и предоставляется автоматически при установке.

Основные методы 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() возвращает оценку пропускной способности нисходящего канала в кбит/с, что позволяет адаптировать качество контента под скорость соединения.

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, что приведёт к утечке памяти. В архитектуре 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. Он регистрирует колбэк при старте и отменяет его при завершении жизненного цикла. Асинхронная работа обеспечивается через корутины и 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-объектом без платформенных зависимостей.