Logcat — co to jest, poziomy logowania i praca z logami

Czym jest Logcat w Android

Logcat — to systemowy bufor Androida, do którego wszystkie procesy (w tym jądro Linux, system_server i aplikacje) zapisują komunikaty w określonym formacie. Narzędzie logcat, wchodzące w skład Android SDK, odczytuje ten bufor i wyświetla komunikaty w czasie rzeczywistym. Od Androida 4.1 (API 16) dostęp do Logcat jest ograniczony: aplikacje mogą czytać tylko swoje logi, a logi systemowe są dostępne przez ADB z dostępem debug.

Każdy komunikat Logcat zawiera pięć pól: datę i czas, PID (identyfikator procesu), TID (identyfikator wątku), poziom logowania i tag. Format jest stały i taki sam dla wszystkich wersji Androida. Umożliwia to używanie narzędzi grep, awk i sed do filtrowania logów w pipeline CI/CD bez przywiązania do IDE.

Logi są przechowywane w buforze cyklicznym o stałym rozmiarze: 256 KB dla main, 256 KB dla system i 256 KB dla events (Android 5+). Po przepełnieniu bufora stare komunikaty są usuwane. Programista może zmienić rozmiar bufora przez PROP logcat.size lub w ustawieniach programisty urządzenia.

Poziomy logów i tagi: struktura komunikatu Logcat

Sześć poziomów logowania określa ważność komunikatu. Android używa standardowych poziomów, podobnych do innych platform, ale z własnymi nazwami stałych w klasie Log. Wybór odpowiedniego poziomu pomaga skutecznie filtrować logi i nie zagłuszać krytycznych komunikatów drugorzędnymi.

Tagi: organizacja komunikatów według modułów

Tag — ciąg do 23 znaków identyfikujący źródło komunikatu. Zaleca się używanie nazwy klasy lub modułu jako taga: MainActivity, AuthManager, NetworkModule. Umożliwia to filtrowanie logów według konkretnego komponentu aplikacji. Dla spójności w zespole można utworzyć stałe tagów w osobnym pliku lub użyć biblioteki Timber, która automatycznie podstawia tag według nazwy klasy.

Logi crashy i stack trace wyjątków

Przy nieobsłużonym wyjątku Android sam zapisuje w Logcat pełny stack trace z wskazaniem klasy, metody, linii kodu i łańcucha wywołań. Log crasha zawiera typ wyjątku (NullPointerException, RuntimeException), komunikat i sekwencję wywołań od punktu awarii do entry point aplikacji. Do analizy logów crashy z urządzeń użytkowników używa się Firebase Crashlytics, który synchronizuje stack trace z mapą obfuskacji (mapping.txt dla Androida).

Logcat w Android Studio: interfejs, filtry i wyszukiwanie

Android Studio udostępnia graficzny interfejs Logcat, dostępny przez View → Tool Windows → Logcat (Alt + 6). Okno Logcat aktualizuje się w czasie rzeczywistym, pokazuje wszystkie komunikaty podłączonego urządzenia i pozwala konfigurować elastyczne filtry do wyodrębniania potrzebnych informacji z ogólnego strumienia.

Filtrowanie według poziomu i taga

Lista rozwijana Log Level filtruje komunikaty według minimalnego poziomu: wybierz WARN, aby widzieć tylko ostrzeżenia i błędy, ukrywając VERBOSE, DEBUG i INFO. Pole Search umożliwia wyszukiwanie według tekstu komunikatu lub taga — obsługuje regex, co jest wygodne do wyszukiwania komunikatów według wzorca.

Zapisane filtry

Saved Filters — potężna funkcja Logcat w Android Studio. Możesz utworzyć filtr, który pokazuje tylko komunikaty z tagiem twojej aplikacji (tag:MyApp) i poziomem WARN+. Filtry są zapisywane między sesjami i dostępne z listy rozwijanej. Dla projektów z wieloma modułami utwórz osobny filtr dla każdego modułu.

# Przykładowe wyrażenie do filtrowania logów aplikacji
tag:"MyApp" level:WARN # Tylko WARN+ dla MyApp
package:"com.mycompany" # Wszystkie logi pakietu
-tag:"okhttp" # Wyklucz logi OkHttp

Eksport i analiza

Logi Logcat można eksportować do pliku tekstowego przez ikonę Save to File. Jest to przydatne do dołączania do zgłoszeń w Jira lub analizy długich sesji. Wyeksportowany log można otworzyć w dowolnym edytorze tekstu i zastosować grep do wyszukiwania wzorców. Do sformatowanego podglądu użyj narzędzia logcat-color.

ADB logcat: polecenia terminala do zaawansowanej pracy

ADB logcat — konsolowa wersja Logcat, dostępna przez Android Debug Bridge. Jej główną zaletą jest możliwość uruchomienia na serwerach CI, w skryptach automatyzacji i na urządzeniach bez Android Studio. ADB logcat obsługuje wszystkie te same filtry co GUI, ale z elastycznością wiersza poleceń.

Podstawowe polecenia

Polecenie adb logcat bez argumentów wyświetla cały bufor w czasie rzeczywistym. Do zatrzymania użyj Ctrl+C. Flaga -c czyści bufor przed rozpoczęciem zapisu — jest to wygodne, gdy trzeba wyizolować logi bieżącego testu od poprzednich komunikatów. Flaga -b wybiera typ bufora: main, system, events, crash (Android 12+).

# Wyczyść bufor i rozpocznij zapis logów z tagiem MyApp
adb logcat -c
adb logcat MyApp:D *:S

# Zapisz logi do pliku
adb logcat -d > logcat_dump.txt

# Filtrowanie według PID procesu
adb logcat --pid=12345

Filtrowanie przez grep i awk

Połączenie ADB z narzędziami uniksowymi daje maksymalną elastyczność. Na przykład filtr "*:S TAG:D" pokazuje tylko komunikaty z tagiem TAG o poziomie DEBUG i wyższym, ukrywając wszystkie inne. Do przeglądania tylko Exception użyj grep -i exception. Do analizy częstotliwości błędów zastosuj sort | uniq -c na kolumnie taga.

Logcat w CI/CD

Na serwerach CI Logcat jest używany do zbierania diagnostyki podczas uruchamiania testów UI. Typowy pipeline: przed uruchomieniem testów bufor jest czyszczony, po wykonaniu testów — zrzut logów jest zapisywany jako artefakt kompilacji. Jeśli test się nie powiódł, na podstawie logów można określić, czy awaria została spowodowana przez ANR, nieobsłużony wyjątek lub timeout sieciowy.

Logowanie w kodzie: Log.d, Log.e i Timber

Klasa android.util.Log — wbudowane API do zapisywania komunikatów w Logcat. Log.v, Log.d, Log.i, Log.w, Log.e i Log.wtf przyjmują tag (ciąg) i komunikat (ciąg) lub komunikat + Throwable. Do formatowania komunikatów używaj String.format lub Kotlin String templates — unikaj konkatenacji ciągów, która tworzy zbędne obiekty w stercie.

Biblioteka Timber

Timber — popularna biblioteka Jake'a Whartona, która eliminuje wady wbudowanego API Log. Timber automatycznie podstawia tag według nazwy klasy, która wywołała logowanie, i nie wymaga przekazywania tagu w każdym wywołaniu. Timber obsługuje również warunkowe logowanie: w kompilacji Release wywołania Timber.v i Timber.d można wyłączyć jedną linią w Application.onCreate.

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

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

        // Timber — automatyczny tag na podstawie nazwy klasy
        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")
        }
    }
}

Warunkowe logowanie dla Release

W kompilacji Release zaleca się wyłączenie logów VERBOSE i DEBUG, aby zmniejszyć obciążenie bufora Logcat i wykluczyć wyciek wrażliwych informacji. Timber rozwiązuje to zadanie przez PlantingTree: w flavorze Debug sadzony jest DebugTree (loguje wszystko), w Release — CrashReportingTree (loguje tylko ERROR przez Crashlytics). Wbudowane API Log nie obsługuje warunkowego logowania — programista musi opakować każde wywołanie w if (BuildConfig.DEBUG).