Logcat — vad är det, loggnivåer och arbete med loggar

Vad är Logcat i Android

Logcat — är en systembuffert i Android där alla processer (inklusive Linux-kärnan, system_server och applikationer) skriver meddelanden i ett specifikt format. Verktyget logcat, som ingår i Android SDK, läser denna buffert och visar meddelanden i realtid. Från och med Android 4.1 (API 16) är åtkomsten till Logcat begränsad: applikationer kan bara läsa sina egna loggar och systemloggar är tillgängliga via ADB med debug-åtkomst.

Varje Logcat-meddelande innehåller fem fält: datum och tid, PID (processidentifierare), TID (trådidentifierare), loggnivå och tagg. Formatet är fast och samma för alla Android-versioner. Detta gör det möjligt att använda grep-, awk- och sed-verktyg för filtrering av loggar i CI/CD-pipelines utan beroende av IDE.

Loggar lagras i en cirkulär buffert med fast storlek: 256 KB för main, 256 KB för system och 256 KB för events (Android 5+). När bufferten svämmar över raderas gamla meddelanden. Utvecklaren kan ändra buffertstorleken via PROP logcat.size eller i enhetens utvecklarinställningar.

Loggnivåer och taggar: struktur för ett Logcat-meddelande

Sex nivåer av loggning bestämmer meddelandets viktighet. Android använder standardnivåer som liknar andra plattformar, men med egna konstantnamn i klassen Log. Att välja rätt nivå hjälper till att effektivt filtrera loggar och undvika att kritiska meddelanden drunknar i sekundära.

Taggar: organisering av meddelanden efter modul

Tagg (tag) — en sträng på upp till 23 tecken som identifierar meddelandets källa. Det rekommenderas att använda klass- eller modulnamnet som tagg: MainActivity, AuthManager, NetworkModule. Detta gör det möjligt att filtrera loggar efter en specifik komponent i applikationen. För enhetlighet i teamet kan taggkonstanter skapas i en separat fil eller så kan biblioteket Timber användas som automatiskt sätter taggen baserat på klassnamnet.

Kraschloggar och undantags stack trace

Vid ohanterat undantag skriver Android själv en fullständig stack trace i Logcat med angivelse av klass, metod, kodrad och anropskedja. Kraschloggen innehåller undantagstypen (NullPointerException, RuntimeException), meddelandet och anropssekvensen från kraschens punkt till applikationens startpunkt. För analys av kraschloggar från användarenheter används Firebase Crashlytics som synkroniserar stack trace med obfuskeringskartan (mapping.txt för Android).

Logcat i Android Studio: gränssnitt, filter och sökning

Android Studio tillhandahåller ett grafiskt Logcat-gränssnitt som nås via View → Tool Windows → Logcat (Alt + 6). Logcat-fönstret uppdateras i realtid, visar alla meddelanden från den anslutna enheten och gör det möjligt att konfigurera flexibla filter för att extrahera nödvändig information från det allmänna flödet.

Filtrering efter nivå och tagg

Rullgardinslistan Log Level filtrerar meddelanden efter miniminivå: välj WARN för att endast se varningar och fel, med VERBOSE, DEBUG och INFO dolda. Sökfältet gör det möjligt att söka efter meddelandetext eller tagg — stöder regex, vilket är praktiskt för att söka efter meddelanden enligt mönster.

Sparade filter

Saved Filters — en kraftfull funktion i Logcat i Android Studio. Du kan skapa ett filter som endast visar meddelanden med din applikations tagg (tag:MyApp) och nivå WARN+. Filter sparas mellan sessioner och är tillgängliga från rullgardinslistan. För projekt med flera moduler, skapa ett separat filter för varje modul.

# Exempeluttryck för filtrering av applikationsloggar
tag:"MyApp" level:WARN # Endast WARN+ för MyApp
package:"com.mycompany" # Alla loggar i paketet
-tag:"okhttp" # Exkludera OkHttp-loggar

Export och analys

Logcat-loggar kan exporteras till en textfil via ikonen Save to File. Detta är användbart för att bifoga till ärenden i Jira eller analysera långa sessioner. Den exporterade loggen kan öppnas i vilken textredigerare som helst och grep kan tillämpas för att söka efter mönster. För formaterad visning, använd verktyget logcat-color.

ADB logcat: terminalkommandon för avancerat arbete

ADB logcat — konsolversionen av Logcat, tillgänglig via Android Debug Bridge. Dess främsta fördel är möjligheten att köras på CI-servrar, i automatiseringsskript och på enheter utan Android Studio. ADB logcat stöder alla samma filter som GUI, men med kommandoradens flexibilitet.

Grundläggande kommandon

Kommandot adb logcat utan argument visar hela bufferten i realtid. För att stoppa, använd Ctrl+C. Flaggan -c rensar bufferten innan inspelningen startar — detta är praktiskt när du behöver isolera loggarna för det aktuella testet från tidigare meddelanden. Flaggan -b väljer bufferttyp: main, system, events, crash (Android 12+).

# Rensa bufferten och starta loggning med taggen MyApp
adb logcat -c
adb logcat MyApp:D *:S

# Spara loggar till fil
adb logcat -d > logcat_dump.txt

# Filtrering efter processens PID
adb logcat --pid=12345

Filtrering med grep och awk

Kombinationen av ADB med unix-verktyg ger maximal flexibilitet. Till exempel visar filtret "*:S TAG:D" endast meddelanden med taggen TAG på nivå DEBUG och högre, och döljer alla andra. För att endast se Exception, använd grep -i exception. För analys av felfrekvens, tillämpa sort | uniq -c på taggkolumnen.

Logcat i CI/CD

På CI-servrar används Logcat för att samla in diagnostik vid körning av UI-tester. En typisk pipeline: innan testerna startar rensas bufferten, efter att testerna har körts sparas loggutskriften som en byggartefakt. Om ett test misslyckas kan man baserat på loggarna avgöra om felet orsakades av ANR, ett ohanterat undantag eller en nätverkstimeout.

Loggning i kod: Log.d, Log.e och Timber

Klassen android.util.Log — det inbyggda API:et för att skriva meddelanden till Logcat. Log.v, Log.d, Log.i, Log.w, Log.e och Log.wtf accepterar en tagg (sträng) och ett meddelande (sträng) eller meddelande + Throwable. För att formatera meddelanden, använd String.format eller Kotlin String templates — undvik strängkonkatenering som skapar extra objekt på heapen.

Biblioteket Timber

Timber — ett populärt bibliotek av Jake Wharton som eliminerar bristerna i det inbyggda Log API:et. Timber sätter automatiskt taggen baserat på klassnamnet som anropade loggningen och kräver inte att taggen skickas vid varje anrop. Timber stöder också villkorlig loggning: i en Release-bygg kan anrop till Timber.v och Timber.d stängas av med en rad i Application.onCreate.

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

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

        // Timber — automatisk tagg baserad på klassnamn
        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")
        }
    }
}

Villkorlig loggning för Release

I en Release-bygg rekommenderas att VERBOSE- och DEBUG-loggar stängs av för att minska belastningen på Logcat-bufferten och utesluta läckage av känslig information. Timber löser denna uppgift genom PlantingTree: i Debug-flavorn planteras DebugTree (loggar allt), i Release — CrashReportingTree (loggar endast ERROR via Crashlytics). Det inbyggda Log API:et stöder inte villkorlig loggning — utvecklaren måste omsluta varje anrop med if (BuildConfig.DEBUG).