Logcat — qu'est-ce que c'est, niveaux de logging et travail avec les logs

Qu'est-ce que Logcat dans Android

Logcat est un tampon système Android dans lequel tous les processus (y compris le noyau Linux, system_server et les applications) écrivent des messages dans un format spécifique. L'outil logcat, inclus dans le SDK Android, lit ce tampon et affiche les messages en temps réel. À partir d'Android 4.1 (API 16), l'accès à Logcat est restreint : les applications ne peuvent lire que leurs propres logs, et les logs système sont accessibles via ADB avec un accès de débogage.

Chaque message Logcat contient cinq champs : date et heure, PID (identifiant de processus), TID (identifiant de thread), niveau de log et tag. Le format est fixe et identique dans toutes les versions d'Android. Cela permet d'utiliser les utilitaires grep, awk et sed pour le filtrage des logs dans les pipelines CI/CD sans dépendance à l'IDE.

Les logs sont stockés dans un tampon circulaire de taille fixe : 256 Ko pour main, 256 Ko pour system et 256 Ko pour events (Android 5+). Lorsque le tampon déborde, les anciens messages sont supprimés. Le développeur peut modifier la taille du tampon via la propriété PROP logcat.size ou dans les options développeur de l'appareil.

Niveaux de log et tags : structure du message Logcat

Six niveaux de journalisation déterminent l'importance du message. Android utilise des niveaux standard similaires à d'autres plateformes mais avec ses propres noms de constantes dans la classe Log. Choisir le bon niveau permet de filtrer efficacement les logs et d'éviter que les messages critiques soient noyés parmi les messages secondaires.

Tags : organisation des messages par modules

Le tag est une chaîne de jusqu'à 23 caractères qui identifie la source du message. Il est recommandé d'utiliser le nom de la classe ou du module comme tag : MainActivity, AuthManager, NetworkModule. Cela permet de filtrer les logs par un composant spécifique de l'application. Pour l'uniformité dans l'équipe, vous pouvez créer des constantes de tags dans un fichier séparé ou utiliser la bibliothèque Timber, qui insère automatiquement le tag en fonction du nom de la classe.

Logs de crash et stack trace d'exceptions

Lorsqu'une exception non gérée se produit, Android écrit automatiquement la stack trace complète dans Logcat, indiquant la classe, la méthode, la ligne de code et la chaîne d'appels. Le log de crash contient le type d'exception (NullPointerException, RuntimeException), le message et la séquence d'appels du point de plantage jusqu'au point d'entrée de l'application. Pour analyser les logs de crash des appareils utilisateurs, Firebase Crashlytics est utilisé, qui synchronise la stack trace avec la carte d'obfuscation (mapping.txt pour Android).

Logcat dans Android Studio : interface, filtres et recherche

Android Studio fournit une interface graphique Logcat accessible via View → Tool Windows → Logcat (Alt + 6). La fenêtre Logcat se met à jour en temps réel, affiche tous les messages de l'appareil connecté et permet de configurer des filtres flexibles pour isoler les informations souhaitées du flux général.

Filtrage par niveau et tag

La liste déroulante Log Level filtre les messages par niveau minimum : sélectionnez WARN pour voir uniquement les avertissements et erreurs, en masquant VERBOSE, DEBUG et INFO. Le champ Search permet de rechercher par texte de message ou tag — les expressions régulières sont prises en charge, ce qui est pratique pour trouver des messages par motif.

Filtres enregistrés

Les Saved Filters sont une fonctionnalité puissante de Logcat dans Android Studio. Vous pouvez créer un filtre qui affiche uniquement les messages avec le tag de votre application (tag:MyApp) et le niveau WARN+. Les filtres sont conservés entre les sessions et disponibles dans la liste déroulante. Pour les projets avec plusieurs modules, créez un filtre séparé pour chaque module.

# Exemple d'expression pour filtrer les logs de l'application
tag:"MyApp" level:WARN # Uniquement WARN+ pour MyApp
package:"com.mycompany" # Tous les logs du package
-tag:"okhttp" # Exclure les logs OkHttp

Exportation et analyse

Les logs Logcat peuvent être exportés dans un fichier texte via l'icône Save to File. C'est utile pour les joindre à des tickets Jira ou analyser de longues sessions. Le log exporté peut être ouvert dans n'importe quel éditeur de texte et grep peut être appliqué pour rechercher des motifs. Pour une visualisation formatée, utilisez l'utilitaire logcat-color.

ADB logcat : commandes terminal pour le travail avancé

ADB logcat est la version console de Logcat, accessible via Android Debug Bridge. Son principal avantage est la possibilité de s'exécuter sur des serveurs CI, dans des scripts d'automatisation et sur des appareils sans Android Studio. ADB logcat prend en charge tous les mêmes filtres que l'interface graphique, mais avec la flexibilité de la ligne de commande.

Commandes de base

La commande adb logcat sans arguments affiche tout le tampon en temps réel. Utilisez Ctrl+C pour arrêter. Le drapeau -c vide le tampon avant de commencer l'enregistrement — c'est pratique lorsque vous devez isoler les logs du test actuel des messages précédents. Le drapeau -b sélectionne le type de tampon : main, system, events, crash (Android 12+).

# Vider le tampon et démarrer l'enregistrement des logs avec le tag MyApp
adb logcat -c
adb logcat MyApp:D *:S

# Sauvegarder les logs dans un fichier
adb logcat -d > logcat_dump.txt

# Filtrage par PID du processus
adb logcat --pid=12345

Filtrage avec grep et awk

Combiner ADB avec les utilitaires Unix offre une flexibilité maximale. Par exemple, le filtre "*:S TAG:D" affiche uniquement les messages avec le tag TAG de niveau DEBUG et supérieur, masquant tous les autres. Pour voir uniquement les exceptions, utilisez grep -i exception. Pour analyser la fréquence des erreurs, appliquez sort | uniq -c sur la colonne du tag.

Logcat dans CI/CD

Sur les serveurs CI, Logcat est utilisé pour collecter des diagnostics pendant l'exécution des tests UI. Un pipeline typique : vider le tampon avant d'exécuter les tests, sauvegarder le dump des logs comme artefact de build après l'exécution des tests. Si un test échoue, les logs peuvent déterminer si l'échec a été causé par ANR, une exception non gérée ou un timeout réseau.

Journalisation dans le code : Log.d, Log.e et Timber

La classe android.util.Log est l'API intégrée pour écrire des messages dans Logcat. Log.v, Log.d, Log.i, Log.w, Log.e et Log.wtf acceptent un tag (chaîne) et un message (chaîne) ou un message + Throwable. Pour formater les messages, utilisez String.format ou les modèles de chaîne Kotlin — évitez la concaténation de chaînes qui crée des objets inutiles dans le heap.

Bibliothèque Timber

Timber est une bibliothèque populaire de Jake Wharton qui corrige les défauts de l'API Log intégrée. Timber insère automatiquement le tag en fonction du nom de la classe qui a appelé la journalisation et ne nécessite pas de passer un tag à chaque appel. Timber prend également en charge la journalisation conditionnelle : dans les builds Release, les appels Timber.v et Timber.d peuvent être désactivés avec une seule ligne dans Application.onCreate.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // API Log intégrée
        Log.d("MainActivity", "onCreate called")

        // Timber — tag automatique par nom de classe
        Timber.d("onCreate called")
    }

    private fun loadData() {
        try {
            val result = fetchFromNetwork()
            Timber.i("Data loaded: $result")
        } catch (e: IOException) {
            Timber.e(e, "Failed to load data")
        }
    }
}

Journalisation conditionnelle pour Release

Dans les builds Release, il est recommandé de désactiver les logs VERBOSE et DEBUG pour réduire la charge du tampon Logcat et éviter les fuites d'informations sensibles. Timber résout ce problème avec PlantingTree : dans la variante Debug, DebugTree est planté (journalise tout), dans Release — CrashReportingTree (journalise uniquement ERROR via Crashlytics). L'API Log intégrée ne prend pas en charge la journalisation conditionnelle — le développeur doit encapsuler chaque appel avec if (BuildConfig.DEBUG).