Logcat-Grundlagen: Logs lesen, filtern und Bugs finden

Wenn deine Android-App abstürzt, sich seltsam verhält oder einfach nicht das tut, was du erwartest, brauchst du einen verlässlichen Blick in ihr Innenleben. Genau dafür gibt es Logcat: das Werkzeug in Android Studio, das dir Laufzeit-Meldungen, Stacktraces und System-Hinweise direkt aus dem Gerät oder Emulator anzeigt. Dieser Artikel zeigt dir, was Logcat ist, wie du Logs gezielt liest und welche Regeln dich vor typischen Anfängerfehlern bewahren.

Was ist das?

Logcat ist Androids zentrales Logging-System. Jede App, jeder Systemdienst und der Kernel selbst schreiben dort Nachrichten hinein, die mit Zeitstempel, Prozess-ID, Tag und Schweregrad versehen sind. In Android Studio findest du Logcat als eigenes Tool-Fenster, auf der Kommandozeile rufst du es über adb logcat auf. Die wichtigste Aufgabe: dir zeigen, was deine App zur Laufzeit wirklich tut, und nicht nur, was du beim Schreiben angenommen hast.

Im modernen Android-Stack mit Kotlin, Jetpack und Compose ist Logcat der schnellste Weg, um Zustandsänderungen, Recompositions, ViewModel-Logik oder Coroutine-Fehler zu beobachten. Du kannst zwar mit dem Debugger Breakpoints setzen, aber Logcat liefert dir den fortlaufenden Strom aller Ereignisse — auch dann, wenn die App auf einem echten Gerät läuft, das Debugger-Pausen schlecht verträgt. Für UI-Animationen, Touch-Eingaben oder Netzwerk-Timing ist diese kontinuierliche Sicht oft unverzichtbar.

Wie funktioniert es?

Logcat unterscheidet fünf Schweregrade, die du in dieser Reihenfolge merken solltest: Verbose (V), Debug (D), Info (I), Warn (W), Error (E). Dazu kommt noch Assert (A) für harte Fehler. Jeder Eintrag bekommt einen Tag — eine kurze Zeichenkette, die das Subsystem benennt, etwa MainActivity oder LoginViewModel. Filterst du in Android Studio nach Tag oder Schweregrad, blendest du den Lärm anderer Komponenten aus.

Geschrieben werden Logs aus deinem Code mit der Klasse android.util.Log. Methoden wie Log.d(tag, message) oder Log.e(tag, message, throwable) legen den Eintrag im Ringpuffer des Geräts ab. Dieser Puffer ist begrenzt: Sobald er voll ist, fallen alte Nachrichten heraus. Bei stark loggenden Apps kannst du also wichtige Hinweise verlieren, wenn du nicht früh genug filterst oder den Puffer per adb logcat -G vergrößerst.

Tag-Konvention

Halte Tags kurz und konsistent. Eine bewährte Faustregel: ein Tag pro Klasse, identisch zum Klassennamen. So findest du eigene Einträge schnell wieder, und Logcat-Filter bleiben übersichtlich. Vermeide es, Tags dynamisch aus Strings zusammenzubauen — das macht das spätere Filtern unnötig kompliziert.

In der Praxis

Stell dir vor, du baust einen Login-Bildschirm mit Compose und einem ViewModel. Du willst sehen, ob der Klick auf den Anmelde-Button überhaupt im ViewModel ankommt und welcher Zustand danach gesetzt wird.

class LoginViewModel(
    private val repository: AuthRepository
) : ViewModel() {

    private val tag = "LoginViewModel"

    fun onSubmit(email: String) {
        Log.d(tag, "onSubmit aufgerufen, email=${email.take(3)}***")
        viewModelScope.launch {
            try {
                val result = repository.login(email)
                Log.i(tag, "Login erfolgreich für userId=${result.id}")
            } catch (e: Exception) {
                Log.e(tag, "Login fehlgeschlagen", e)
            }
        }
    }
}

Mit diesem Setup öffnest du Logcat, filterst auf den Tag LoginViewModel und erkennst Schritt für Schritt, was passiert. Die Log.e-Variante mit Throwable ist besonders nützlich, weil Android Studio dir den vollständigen Stacktrace inklusive klickbarer Zeilennummern anzeigt — ein Klick, und du landest direkt an der Fehlerstelle.

Stolperfalle: Logs in Produktion

Der häufigste Anfängerfehler: persönliche Daten oder vollständige API-Antworten loggen und das Logging dann im Release-Build vergessen. Logcat-Einträge können von anderen Apps mit entsprechender Berechtigung oder über adb ausgelesen werden, und in Crash-Reports landen sie ebenfalls. Filtere sensible Inhalte deshalb immer (siehe email.take(3)*** oben) und entferne Log.d- und Log.v-Aufrufe in Release-Builds — etwa über ein Wrapper-Objekt mit BuildConfig.DEBUG-Check oder über die Bibliothek Timber, die genau diesen Mechanismus zuverlässig automatisiert.

Fazit

Logcat ist dein wichtigstes Werkzeug, um deine App in Aktion zu beobachten. Lerne früh, gezielt nach Tag und Schweregrad zu filtern, schreibe konsistente Tags und vermeide Logs mit sensiblen Daten in Release-Builds. Öffne jetzt dein letztes Projekt, lass es auf einem Emulator laufen und filtere die Ausgabe einmal nach einem deiner ViewModels — du wirst überrascht sein, wie viele Hinweise du bisher übersehen hast. Ergänze gezielte Log.d-Aufrufe an Stellen, an denen du Zustandsänderungen vermutest, und prüfe deine Annahmen so im laufenden System statt nur im Kopf.