FR
RU
EN
ES
ZH
DE
PT
AR
HI
Un matin qui commence par une NetworkOnMainThreadException
\n\nVous développez une application Android. Tout se passe bien, jusqu'à ce que vous décidiez de faire une simple requête HTTP dans un bouton. Vous appuyez sur « Actualiser » — et l'application plante avec une pile d'appels rouge. Cela vous dit quelque chose ? android.os.NetworkOnMainThreadException est une erreur classique que tout développeur Android a vue au moins une fois dans sa vie. En 2025, elle est toujours d'actualité, et les débutants continuent de tomber dans le même piège.
\n\nDans cet article, nous allons voir pourquoi NetworkOnMainThreadException se produit, comment la corriger en Java, et quelles approches sont considérées comme les meilleures pratiques en 2025. Vous obtiendrez des solutions prêtes à l'emploi avec du code que vous pouvez immédiatement intégrer dans votre projet.
\n\nPourquoi NetworkOnMainThreadException se produit-elle ?
\n\nAndroid n'est pas simplement Java. C'est un système avec des règles strictes. L'une d'elles : n'effectuez pas d'opérations réseau dans le thread principal (UI). Le thread principal est responsable du rendu de l'interface et du traitement des touches. S'il se bloque ne serait-ce qu'une seconde, l'utilisateur verra des « ralentissements », et s'il se bloque pendant cinq secondes, le système affichera une boîte de dialogue « L'application ne répond pas » (ANR).
\n\nDepuis Android 3.0 (Honeycomb), Google a ajouté une protection : tout appel réseau dans le thread principal lève une android.os.NetworkOnMainThreadException. Cette exception signifie : « Hé, tu fais quelque chose de dangereux pour l'expérience utilisateur ! ».
En 2025, cette règle n'a pas disparu. Même si vous utilisez des bibliothèques modernes (Retrofit, OkHttp), vous êtes toujours obligé de les exécuter dans un thread d'arrière-plan. L'exception n'est pas un bug, mais une fonctionnalité de sécurité.
\n\nTop 5 des façons de corriger l'erreur (Java, 2025)
\n\nNous allons examiner cinq approches — des plus anciennes aux plus modernes. Choisissez celle qui convient à votre projet.
\n\n1. AsyncTask classique (legacy, mais fonctionnel)
\n\nAsyncTask était la norme il y a environ 10 ans. En 2025, son utilisation n'est pas recommandée (il est déprécié depuis l'API 30+), mais vous pouvez encore le rencontrer sur d'anciens projets.
\n\nprivate class MyNetworkTask extends AsyncTask<String, Void, String> {\n @Override\n protected String doInBackground(String... params) {\n // C'est déjà un thread d'arrière-plan\n try {\n URL url = new URL(params[0]);\n HttpURLConnection connection = (HttpURLConnection) url.openConnection();\n BufferedReader reader = new BufferedReader(new InputStreamReader(connection.getInputStream()));\n StringBuilder result = new StringBuilder();\n String line;\n while ((line = reader.readLine()) != null) {\n result.append(line);\n }\n return result.toString();\n } catch (Exception e) {\n return "Erreur : " + e.getMessage();\n }\n }\n\n @Override\n protected void onPostExecute(String result) {\n // C'est déjà le thread UI\n textView.setText(result);\n }\n}\n\n// Lancement :\nnew MyNetworkTask().execute("https://api.example.com/data");Inconvénients : AsyncTask est difficile à tester, peu pratique pour les chaînes de requêtes, et peut provoquer des fuites mémoire en cas de rotation de l'écran. Utilisez-le uniquement si le projet est écrit en Java 7-8.
\n\n2. Java Thread + Handler (approche pure)
\n\nLa façon la plus simple est de créer un thread séparé et de renvoyer le résultat à l'UI via un Handler.
\n\nprivate Handler mainHandler = new Handler(Looper.getMainLooper());\n\nprivate void fetchDataInBackground() {\n new Thread(new Runnable() {\n @Override\n public void run() {\n // Thread d'arrière-plan\n final String result = performNetworkCall();\n \n // Retour au thread UI\n mainHandler.post(new Runnable() {\n @Override\n public void run() {\n textView.setText(result);\n }\n });\n }\n }).start();\n}\n\nprivate String performN 
