Logcat — wat is het, logniveaus en werken met logs

Wat is Logcat in Android

Logcat — is een systeembuffer van Android waarin alle processen (inclusief de Linux-kernel, system_server en applicaties) berichten in een specifiek formaat schrijven. De tool logcat, onderdeel van de Android SDK, leest deze buffer en toont berichten in realtime. Vanaf Android 4.1 (API 16) is de toegang tot Logcat beperkt: applicaties kunnen alleen hun eigen logs lezen en systeemlogs zijn toegankelijk via ADB met debug-toegang.

Elk Logcat-bericht bevat vijf velden: datum en tijd, PID (procesidentificatie), TID (thread-identificatie), logniveau en tag. Het formaat is vast en hetzelfde voor alle Android-versies. Dit maakt het mogelijk om grep-, awk- en sed-hulpprogramma's te gebruiken voor het filteren van logs in CI/CD-pijplijnen zonder afhankelijkheid van IDE.

Logs worden opgeslagen in een circulaire buffer met vaste grootte: 256 KB voor main, 256 KB voor system en 256 KB voor events (Android 5+). Bij overloop van de buffer worden oude berichten verwijderd. De ontwikkelaar kan de buffergrootte wijzigen via PROP logcat.size of in de ontwikkelaarsinstellingen van het apparaat.

Logniveaus en tags: structuur van een Logcat-bericht

Zes niveaus van loggen bepalen het belang van het bericht. Android gebruikt standaardniveaus vergelijkbaar met andere platforms, maar met eigen constantenamen in de klasse Log. Het kiezen van het juiste niveau helpt bij het effectief filteren van logs en voorkomt dat kritieke berichten worden overspoeld door secundaire.

Tags: organisatie van berichten per module

Tag — een tekenreeks tot 23 tekens die de bron van het bericht identificeert. Het wordt aanbevolen de klasse- of modulenaam als tag te gebruiken: MainActivity, AuthManager, NetworkModule. Dit maakt het mogelijk logs te filteren op een specifieke component van de applicatie. Voor uniformiteit in het team kunnen tag-constanten in een apart bestand worden gemaakt of kan de bibliotheek Timber worden gebruikt die automatisch de tag op basis van de klassenaam instelt.

Crashlogs en Exception stack trace

Bij een onafgehandelde uitzondering schrijft Android zelf een volledige stack trace in Logcat met vermelding van de klasse, methode, coderegel en aanroepketen. Het crashlog bevat het type uitzondering (NullPointerException, RuntimeException), het bericht en de volgorde van aanroepen van het crashpunt tot het entry point van de applicatie. Voor het analyseren van crashlogs van gebruikersapparaten wordt Firebase Crashlytics gebruikt, die de stack trace synchroniseert met de obfuscatiekaart (mapping.txt voor Android).

Logcat in Android Studio: interface, filters en zoeken

Android Studio biedt een grafische Logcat-interface, toegankelijk via View → Tool Windows → Logcat (Alt + 6). Het Logcat-venster wordt in realtime bijgewerkt, toont alle berichten van het aangesloten apparaat en maakt het mogelijk flexibele filters in te stellen om de benodigde informatie uit de algemene stroom te halen.

Filteren op niveau en tag

De vervolgkeuzelijst Log Level filtert berichten op minimumniveau: selecteer WARN om alleen waarschuwingen en fouten te zien, met VERBOSE, DEBUG en INFO verborgen. Het veld Search maakt zoeken op berichttekst of tag mogelijk — ondersteunt regex, wat handig is voor het zoeken naar berichten op patroon.

Opgeslagen filters

Saved Filters — een krachtige functie van Logcat in Android Studio. U kunt een filter maken dat alleen berichten met de tag van uw applicatie (tag:MyApp) en niveau WARN+ toont. Filters worden tussen sessies bewaard en zijn beschikbaar via de vervolgkeuzelijst. Voor projecten met meerdere modules maakt u een apart filter voor elke module.

# Voorbeeld van een expressie voor het filteren van applicatielogs
tag:"MyApp" level:WARN # Alleen WARN+ voor MyApp
package:"com.mycompany" # Alle logs van het pakket
-tag:"okhttp" # OkHttp-logs uitsluiten

Exporteren en analyseren

Logcat-logs kunnen worden geëxporteerd naar een tekstbestand via het pictogram Save to File. Dit is handig voor bijlagen bij tickets in Jira of het analyseren van lange sessies. De geëxporteerde log kan in elke teksteditor worden geopend en grep kan worden toegepast om patronen te zoeken. Voor een geformatteerde weergave gebruikt u het hulpprogramma logcat-color.

ADB logcat: terminalopdrachten voor gevorderd werk

ADB logcat — de consoleversie van Logcat, beschikbaar via Android Debug Bridge. Het belangrijkste voordeel is de mogelijkheid om te draaien op CI-servers, in automatiseringsscripts en op apparaten zonder Android Studio. ADB logcat ondersteunt allezelfde filters als de GUI, maar met de flexibiliteit van de opdrachtregel.

Basisopdrachten

De opdracht adb logcat zonder argumenten toont de volledige buffer in realtime. Gebruik Ctrl+C om te stoppen. De vlag -c wist de buffer voordat de opname begint — dit is handig wanneer u de logs van de huidige test wilt isoleren van eerdere berichten. De vlag -b selecteert het buffertype: main, system, events, crash (Android 12+).

# Buffer wissen en loggen starten met tag MyApp
adb logcat -c
adb logcat MyApp:D *:S

# Logs opslaan in bestand
adb logcat -d > logcat_dump.txt

# Filteren op PID van het proces
adb logcat --pid=12345

Filteren met grep en awk

Combinatie van ADB met unix-hulpprogramma's biedt maximale flexibiliteit. Bijvoorbeeld, het filter "*:S TAG:D" toont alleen berichten met tag TAG van niveau DEBUG en hoger, en verbergt alle andere. Gebruik grep -i exception om alleen Exception te bekijken. Voor analyse van de foutfrequentie past u sort | uniq -c toe op de tag-kolom.

Logcat in CI/CD

Op CI-servers wordt Logcat gebruikt voor het verzamelen van diagnostiek tijdens het uitvoeren van UI-tests. Een typische pijplijn: voor het starten van tests wordt de buffer gewist, na het uitvoeren van tests wordt de dump van logs opgeslagen als build-artefact. Als een test faalt, kan op basis van de logs worden bepaald of de fout werd veroorzaakt door ANR, een onafgehandelde uitzondering of een netwerk-timeout.

Loggen in code: Log.d, Log.e en Timber

De klasse android.util.Log — de ingebouwde API voor het schrijven van berichten naar Logcat. Log.v, Log.d, Log.i, Log.w, Log.e en Log.wtf accepteren een tag (tekenreeks) en een bericht (tekenreeks) of bericht + Throwable. Gebruik String.format of Kotlin String templates voor het formatteren van berichten — vermijd het samenvoegen van tekenreeksen, wat extra objecten op de heap creëert.

De bibliotheek Timber

Timber — een populaire bibliotheek van Jake Wharton die de tekortkomingen van de ingebouwde Log API wegneemt. Timber stelt automatisch de tag in op basis van de klassenaam die het loggen heeft aangeroepen en vereist geen tag bij elke aanroep. Timber ondersteunt ook voorwaardelijk loggen: in een Release-build kunnen Timber.v- en Timber.d-aanroepen met één regel in Application.onCreate worden uitgeschakeld.

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

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

        // Timber — automatische tag op basis van klassenaam
        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")
        }
    }
}

Voorwaardelijk loggen voor Release

In een Release-build wordt aanbevolen VERBOSE- en DEBUG-logs uit te schakelen om de belasting van de Logcat-buffer te verminderen en lekkage van gevoelige informatie te voorkomen. Timber lost deze taak op via PlantingTree: in de Debug-flavor wordt DebugTree (logt alles) geplant, in Release — CrashReportingTree (logt alleen ERROR via Crashlytics). De ingebouwde Log API ondersteunt geen voorwaardelijk loggen — de ontwikkelaar moet elke aanroep omwikkelen met if (BuildConfig.DEBUG).