Logcat — was ist das, Logging-Level und Arbeit mit Logs

Was ist Logcat in Android

Logcat ist ein Android-Systempuffer, in den alle Prozesse (einschließlich Linux-Kernel, system_server und Anwendungen) Nachrichten in einem bestimmten Format schreiben. Das logcat-Tool, das im Android SDK enthalten ist, liest diesen Puffer und zeigt Nachrichten in Echtzeit an. Ab Android 4.1 (API 16) ist der Zugriff auf Logcat eingeschränkt: Anwendungen können nur ihre eigenen Logs lesen, und Systemlogs sind über ADB mit Debug-Zugriff zugänglich.

Jede Logcat-Nachricht enthält fünf Felder: Datum und Uhrzeit, PID (Prozesskennung), TID (Thread-Kennung), Log-Level und Tag. Das Format ist festgelegt und über alle Android-Versionen hinweg identisch. Dies ermöglicht die Verwendung der Dienstprogramme grep, awk und sed zur Log-Filterung in CI/CD-Pipelines ohne IDE-Abhängigkeit.

Logs werden in einem Ringpuffer fester Größe gespeichert: 256 KB für main, 256 KB für system und 256 KB für events (Android 5+). Wenn der Puffer überläuft, werden alte Nachrichten gelöscht. Der Entwickler kann die Puffergröße über die Eigenschaft PROP logcat.size oder in den Entwickleroptionen des Geräts ändern.

Log-Level und Tags: Struktur der Logcat-Nachricht

Sechs Stufen der Protokollierung bestimmen die Wichtigkeit der Nachricht. Android verwendet Standardstufen ähnlich wie andere Plattformen, jedoch mit eigenen Konstantennamen in der Log-Klasse. Die Wahl der richtigen Stufe hilft, Logs effizient zu filtern und zu vermeiden, dass kritische Nachrichten in sekundären untergehen.

Tags: Organisation von Nachrichten nach Modulen

Ein Tag ist eine Zeichenfolge von bis zu 23 Zeichen, die die Quelle der Nachricht identifiziert. Es wird empfohlen, den Klassen- oder Modulnamen als Tag zu verwenden: MainActivity, AuthManager, NetworkModule. Dies ermöglicht es, Logs nach einer bestimmten Anwendungskomponente zu filtern. Für die Einheitlichkeit im Team können Sie Tag-Konstanten in einer separaten Datei erstellen oder die Bibliothek Timber verwenden, die automatisch das Tag basierend auf dem Klassennamen einfügt.

Crash-Logs und Exception-Stack-Traces

Wenn eine unbehandelte Ausnahme auftritt, schreibt Android automatisch den vollständigen Stack-Trace in Logcat, mit Angabe der Klasse, Methode, Codezeile und Aufrufkette. Ein Crash-Log enthält den Ausnahmetyp (NullPointerException, RuntimeException), die Nachricht und die Aufrufsequenz vom Absturzpunkt bis zum Einstiegspunkt der Anwendung. Zur Analyse von Crash-Logs von Benutzergeräten wird Firebase Crashlytics verwendet, das den Stack-Trace mit der Verschleierungsmap (mapping.txt für Android) synchronisiert.

Logcat in Android Studio: Oberfläche, Filter und Suche

Android Studio bietet eine grafische Logcat-Oberfläche, die über View → Tool Windows → Logcat (Alt + 6) zugänglich ist. Das Logcat-Fenster wird in Echtzeit aktualisiert, zeigt alle Nachrichten des verbundenen Geräts an und ermöglicht die Konfiguration flexibler Filter, um die gewünschten Informationen aus dem allgemeinen Strom zu isolieren.

Filterung nach Stufe und Tag

Die Dropdown-Liste Log Level filtert Nachrichten nach Mindeststufe: wählen Sie WARN, um nur Warnungen und Fehler zu sehen, wobei VERBOSE, DEBUG und INFO ausgeblendet werden. Das Suchfeld ermöglicht die Suche nach Nachrichtentext oder Tag — Regex wird unterstützt, was für die Suche nach Nachrichten mit einem bestimmten Muster praktisch ist.

Gespeicherte Filter

Saved Filters sind eine leistungsstarke Logcat-Funktion in Android Studio. Sie können einen Filter erstellen, der nur Nachrichten mit dem Tag Ihrer Anwendung (tag:MyApp) und der Stufe WARN+ anzeigt. Filter bleiben zwischen Sitzungen erhalten und sind in der Dropdown-Liste verfügbar. Für Projekte mit mehreren Modulen erstellen Sie einen separaten Filter für jedes Modul.

# Beispielausdruck zum Filtern von Anwendungslogs
tag:"MyApp" level:WARN # Nur WARN+ für MyApp
package:"com.mycompany" # Alle Logs des Pakets
-tag:"okhttp" # OkHttp-Logs ausschließen

Export und Analyse

Logcat-Logs können über das Symbol Save to File in eine Textdatei exportiert werden. Dies ist nützlich zum Anhängen an Tickets in Jira oder zur Analyse langer Sitzungen. Das exportierte Log kann in einem beliebigen Texteditor geöffnet und mit grep nach Mustern durchsucht werden. Für eine formatierte Ansicht verwenden Sie das Dienstprogramm logcat-color.

ADB logcat: Terminalbefehle für fortgeschrittene Arbeit

ADB logcat ist die Konsolenversion von Logcat, zugänglich über Android Debug Bridge. Sein Hauptvorteil ist die Möglichkeit, auf CI-Servern, in Automatisierungsskripten und auf Geräten ohne Android Studio ausgeführt zu werden. ADB logcat unterstützt alle gleichen Filter wie die GUI, jedoch mit der Flexibilität der Befehlszeile.

Grundlegende Befehle

Der Befehl adb logcat ohne Argumente gibt den gesamten Puffer in Echtzeit aus. Verwenden Sie Strg+C zum Anhalten. Das Flag -c löscht den Puffer vor Aufnahmebeginn — praktisch, wenn Sie die Logs des aktuellen Tests von vorherigen Nachrichten isolieren möchten. Das Flag -b wählt den Puffertyp aus: main, system, events, crash (Android 12+).

# Puffer leeren und Log-Aufzeichnung mit dem Tag MyApp starten
adb logcat -c
adb logcat MyApp:D *:S

# Logs in Datei speichern
adb logcat -d > logcat_dump.txt

# Filterung nach Prozess-PID
adb logcat --pid=12345

Filterung mit grep und awk

Die Kombination von ADB mit Unix-Dienstprogrammen bietet maximale Flexibilität. Zum Beispiel zeigt der Filter "*:S TAG:D" nur Nachrichten mit dem Tag TAG der Stufe DEBUG und höher an und blendet alle anderen aus. Um nur Ausnahmen anzuzeigen, verwenden Sie grep -i exception. Zur Analyse der Fehlerhäufigkeit wenden Sie sort | uniq -c auf die Tag-Spalte an.

Logcat in CI/CD

Auf CI-Servern wird Logcat verwendet, um während der Ausführung von UI-Tests Diagnosedaten zu sammeln. Eine typische Pipeline: den Puffer vor Testbeginn leeren, den Log-Dump nach Testausführung als Build-Artefakt speichern. Wenn ein Test fehlschlägt, können die Logs feststellen, ob der Fehler durch ANR, eine unbehandelte Ausnahme oder ein Netzwerk-Timeout verursacht wurde.

Logging im Code: Log.d, Log.e und Timber

Die Klasse android.util.Log ist die integrierte API zum Schreiben von Nachrichten in Logcat. Log.v, Log.d, Log.i, Log.w, Log.e und Log.wtf akzeptieren ein Tag (Zeichenfolge) und eine Nachricht (Zeichenfolge) oder eine Nachricht + Throwable. Zum Formatieren von Nachrichten verwenden Sie String.format oder Kotlin-String-Vorlagen — vermeiden Sie Zeichenfolgenverkettung, die unnötige Objekte im Heap erzeugt.

Die Timber-Bibliothek

Timber ist eine beliebte Bibliothek von Jake Wharton, die die Mängel der integrierten Log-API behebt. Timber fügt automatisch das Tag basierend auf dem Klassennamen ein, der das Logging aufgerufen hat, und erfordert nicht die Übergabe eines Tags bei jedem Aufruf. Timber unterstützt auch bedingtes Logging: In Release-Builds können Timber.v- und Timber.d-Aufrufe mit einer einzigen Zeile in Application.onCreate deaktiviert werden.

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

        // Integrierte Log-API
        Log.d("MainActivity", "onCreate called")

        // Timber — automatisches Tag nach Klassennamen
        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")
        }
    }
}

Bedingtes Logging für Release

In Release-Builds wird empfohlen, VERBOSE- und DEBUG-Logs zu deaktivieren, um die Last des Logcat-Puffers zu reduzieren und das Durchsickern sensibler Informationen zu verhindern. Timber löst dieses Problem mit PlantingTree: Im Debug-Flavor wird DebugTree gepflanzt (loggt alles), im Release — CrashReportingTree (loggt nur ERROR über Crashlytics). Die integrierte Log-API unterstützt kein bedingtes Logging — der Entwickler muss jeden Aufruf mit if (BuildConfig.DEBUG) umschließen.