NetworkCallback : ce que c'est, application et gestion réseau sous Android

Qu'est-ce que NetworkCallback ?

NetworkCallback est une classe abstraite du paquet android.net, faisant partie du SDK Android. Elle est conçue pour recevoir des notifications sur les changements d'état de la connexion réseau via le service système ConnectivityManager.

Avant NetworkCallback, les développeurs utilisaient BroadcastReceiver pour suivre les changements réseau. Cette approche nécessitait un enregistrement constant dans le manifeste, fonctionnait avec des délais et ne fournissait pas d'informations détaillées sur les caractéristiques de la connexion. Android 5.0 (API 21) a introduit NetworkCallback comme alternative plus flexible et performante.

Le callback fonctionne de manière asynchrone : l'application s'abonne aux événements via ConnectivityManager, et le système appelle les méthodes du callback lorsque l'état du réseau change. Cela élimine le besoin de sondage périodique du statut réseau, économisant les ressources de la batterie et du CPU.

Comment le callback fonctionne sous Android

ConnectivityManager gère toutes les interfaces réseau de l'appareil — Wi-Fi, données mobiles, Ethernet, VPN. Lorsque l'une de ces interfaces change, le système crée un objet Network et le transmet à la méthode correspondante du callback enregistré. Chaque Network possède un identifiant unique qui change lors de la reconnexion.

Le callback n'est pas lié à un type de réseau spécifique — il peut suivre toutes les interfaces disponibles simultanément. Pour filtrer les types de connexion, on utilise la classe NetworkRequest, qui spécifie les protocoles de transport requis (Wi-Fi, données cellulaires, Ethernet) et les capacités du réseau.

Comment enregistrer NetworkCallback dans votre application

L'enregistrement de NetworkCallback se fait via la méthode ConnectivityManager.registerNetworkCallback. Le premier paramètre est un NetworkRequest.Builder décrivant les exigences réseau, le second est une instance du callback. La permission ACCESS_NETWORK_STATE est requise dans le manifeste.

class NetworkMonitor(private val context: Context) {

    private val connectivityManager =
        context.getSystemService(Context.CONNECTIVITY_SERVICE)
            as ConnectivityManager

    private val callback =
        object : ConnectivityManager.NetworkCallback() {

        override fun onAvailable(network: Network) {
            Log.d("Network", "Available: ${network}")
        }

        override fun onLost(network: Network) {
            Log.d("Network", "Lost: ${network}")
        }
    }

    fun register() {
        connectivityManager.registerNetworkCallback(
            NetworkRequest.Builder().build(), callback
        )
    }

    fun unregister() {
        connectivityManager.unregisterNetworkCallback(callback)
    }
}

Enregistrement dans Activity et Fragment

Il est recommandé d'enregistrer NetworkCallback lorsque l'application est au premier plan et de l'annuler lors du passage en arrière-plan. Dans Activity, utilisez onStart et onStop pour gérer le cycle de vie du callback. Dans Fragment, utilisez onResume et onPause.

Pour simplifier la gestion de l'enregistrement, vous pouvez utiliser des composants Lifecycle-aware. La bibliothèque AndroidX Lifecycle permet de créer un LifecycleObserver personnalisé qui enregistre et annule automatiquement le callback lorsque l'état du cycle de vie change.

Enregistrement dans un Service

Pour les tâches en arrière-plan, l'enregistrement se fait dans un Service ou WorkManager. Notez que sous Android 8+, les services en arrière-plan ont des restrictions de lancement. WorkManager avec NetworkType est un moyen plus fiable d'exécuter des tâches sous un état réseau spécifique, car il est intégré à l'API de compatibilité et respecte le mode Doze.

Principales méthodes de NetworkCallback

NetworkCallback fournit un ensemble de méthodes qui sont appelées lorsque l'état du réseau change. Toutes les méthodes n'ont pas besoin d'être redéfinies — implémentez uniquement celles nécessaires à la tâche spécifique de votre application. onAvailable et onLost sont le minimum requis pour la surveillance de base de la connexion.

Méthode onCapabilitiesChanged

Cette méthode est la clé pour obtenir des informations détaillées sur le réseau. Le paramètre NetworkCapabilities contient des indicateurs : NET_CAPABILITY_INTERNET — accès à internet disponible, NET_CAPABILITY_NOT_METERED — connexion illimitée, NET_CAPABILITY_NOT_ROAMING — pas d'itinérance. On peut également connaître la latence du signal et la bande passante.

Les portails captifs sont un cas particulier : lors de la connexion à un réseau Wi-Fi public via un portail, la méthode onCapabilitiesChanged n'affiche pas immédiatement INTERNET. Le réseau est d'abord disponible mais sans internet — une autorisation via le navigateur est requise. Les développeurs doivent tenir compte de ce délai dans la logique de l'application.

Méthode onBlockedStatusChanged

Appelée lorsque le système bloque le trafic réseau pour l'application — par exemple, lors de l'activation du mode d'économie de données ou de la restriction des données en arrière-plan. onBlockedStatusChanged permet à l'application de savoir que ses requêtes réseau sont temporairement interdites et de passer au traitement local.

Exemples d'implémentation de NetworkCallback

Examinons une implémentation pratique de NetworkCallback pour surveiller l'accès à internet et gérer les portails captifs. L'exemple ci-dessous montre la vérification de NET_CAPABILITY_INTERNET et la validation de la connexion via une requête HTTP au serveur Google.

val networkCallback = object : ConnectivityManager.NetworkCallback() {

    override fun onCapabilitiesChanged(
        network: Network,
        caps: NetworkCapabilities
    ) {
        val hasInternet = caps.hasCapability(
            NetworkCapabilities.NET_CAPABILITY_INTERNET
        )
        val isMetered = caps.hasCapability(
            NetworkCapabilities.NET_CAPABILITY_NOT_METERED
        ).not()

        when {
            hasInternet && isMetered ->
                Log.d("Network", "Mobile data connected")
            hasInternet ->
                Log.d("Network", "Wi-Fi connected")
            else ->
                Log.d("Network", "No internet access")
        }
    }

    override fun onLost(network: Network) {
        Log.d("Network", "Connection lost: ${network}")
        // Arrêter les requêtes réseau
    }
}

Gestion des portails captifs

Lors de la connexion à un réseau public avec autorisation (café, aéroport), le système signale d'abord onAvailable, mais onCapabilitiesChanged peut ne pas afficher INTERNET. Dans ces cas, une vérification supplémentaire via une requête HTTP vers un point d'accès stable, comme https://www.google.com/generate_204, est nécessaire.

Si la requête renvoie le code 204 — internet est disponible. S'il y a une redirection (301, 302, 307) — une autorisation via le navigateur est requise. Dans ce cas, vous pouvez ouvrir une WebView ou un Intent avec l'URL de redirection pour compléter l'authentification sur le portail.

fun Context.validateInternet(network: Network) {
    CoroutineScope(Dispatchers.IO).launch {
        try {
            val url = URL("https://www.google.com/generate_204")
            val connection =
                network.openConnection(url) as HttpURLConnection
            connection.instanceFollowRedirects = false
            connection.connect()
            when (connection.responseCode) {
                HttpURLConnection.HTTP_NO_CONTENT ->
                    Log.d("Network", "Internet is available")
                in HttpURLConnection.HTTP_MOVED_PERM
                        ..HttpURLConnection.HTTP_TEMP_REDIRECT ->
                    Log.d("Network", "Captive portal detected")
            }
            connection.disconnect()
        } catch (e: Exception) {
            Log.e("Network", "Validation failed: ${e.message}")
        }
    }
}

Différences avec les autres méthodes de surveillance réseau

Avant NetworkCallback, la principale méthode de surveillance réseau était BroadcastReceiver avec le filtre android.net.conn.CONNECTIVITY_CHANGE. Cette approche présentait des inconvénients majeurs : des délais de plusieurs secondes, l'absence d'informations sur le type d'interface et une consommation d'énergie accrue due au réveil constant de l'appareil.

Une alternative moderne est LiveData ou StateFlow combinés avec NetworkCallback. Le modèle consiste à encapsuler le callback dans un flux réactif qui notifie automatiquement l'UI des changements d'état. Par exemple, un MutableStateFlow de type NetworkStatus est mis à jour dans les méthodes du callback, et un ViewCollector s'abonne aux changements.

Travail en mode arrière-plan

À partir d'Android 10, les restrictions d'arrière-plan sont plus strictes et NetworkCallback peut ne pas être appelé lorsque l'application est en arrière-plan. Pour les tâches critiques — comme le chargement de données lorsque le réseau devient disponible — utilisez WorkManager avec la contrainte NetworkType.CONNECTED. WorkManager garantit l'exécution de la tâche lorsque les conditions réseau sont remplies.

Sous Android 12+, il existe une restriction sur l'enregistrement dans le manifeste de BroadcastReceiver pour CONNECTIVITY_ACTION. Les développeurs doivent migrer vers NetworkCallback ou utiliser WorkManager. La politique Google Play depuis août 2022 exige la suppression de l'enregistrement dans le manifeste pour cette action.