Android_Tutorial_Lektion12_fotolia_RA_Studio_46292813

Programmier Tutorial: Apps für Android entwickeln – Teil 12: Logging in Android Studio

Je komplexer die eigene Android App wird, desto wahrscheinlicher ist es, dass sich an manchen Stellen im Quellcode Fehler eingeschlichen haben.

Die Fähigkeit die Fehlerursache schnell zu lokalisieren und den Fehler sicher zu beheben, ist für das Erstellen mobiler Anwendungen essentiell.

In dieser Lektion sollen die für die Fehlerlokalisierung notwendigen Kenntnisse vermittelt werden. Dazu werden wir das Logging-System von Android Studio, welches für das Überwachen des Anwendungszustands genutzt wird, ausführlich besprechen und in der Praxis einsetzen.


Das Ausgeben von Log-Meldungen, kurzen Ereignismeldung, ist für die Entwicklung von Android Apps von großer Bedeutung. Mit ihnen kann die Android Anwendung zur Laufzeit überwacht werden. Wir werden daher im Laufe des Kurses immer wieder Log-Meldungen einsetzen, um damit den Zustand unsere App gezielt zu überwachen.

Dabei werden wir zuerst einen TAG, der unsere Log-Meldungen erkennbar macht, erstellen. Anschließend werden wir eigene Log-Meldungen mit verschiedenen Prioritätsstufen ausgeben. Die Log-Meldungen werden wir anschließend in dem Terminal Tool Window, dem Logcat Tool Window und dem Android Device Monitor betrachten. Um unsere eigenen Log-Meldungen schnell zu finden, werden wir die Filterfunktion des Logging-Systems von Android nutzen.

1. Das Logging-System von Android

Das Verhalten der eigenen Anwendung zur Laufzeit kann mit Hilfe von Ereignis- und Zustandsmeldungen (Log-Meldungen) effektiv überwacht werden. Dazu werden kurze Log-Meldungen, die über den Zustand der App informieren, auf der Konsole (Kommandozeile) ausgegeben. Dieses Vorgehen wird als Logging bezeichnet.

In Android werden Apps auf einem Entwicklungssystem programmiert und auf einem anderen System, physikalisches oder virtuelles Android Gerät, ausgeführt. Daraus ergibt sich die Notwendigkeit, die Log-Meldungen von dem Android Gerät an das Entwicklungssystem weiterzuleiten. Für diese Aufgabe ist das Logger-Framework (Logging-System) von Android zuständig.

Es erfasst sämtliche Log-Meldungen des Android Geräts und speichert diese in verschiedenen Ringpuffern (Circular Buffers) ab. Ein Ringpuffer hält seine Daten ähnlich einer verketteten Liste (Linked List), verknüpft jedoch das letzte Element wieder mit dem ersten.

Im Android Logging-System sind folgende Ringpuffer implementiert:

  • radio – Enthält Funk-, Bluetooth- und Telefonie-bezogene Meldungen.
  • events – Enthält Meldungen über Systemereignisse, wie das Erzeugen und Beenden von Services.
  • main – Hierin werden die Meldungen unserer eigenen App abgespeichert.
  • system – Enthält Meldungen über den Zustand der Systemprozesse, bspw. wenn die garbage collection stattfindet.
  • crash – Hierin werden die Meldungen über Anwendungsabstürze abgelegt.

Nur die main, system und crash Log-Meldungen werden standardmäßig ausgegeben. Die Meldungen der radio und events Ringpuffer müssen explizit angefragt werden.

1.1 Auslesen von Log-Meldungen mit dem logcat-Tool

Für das Auslesen und Betrachten von Log-Meldungen werden die beiden Kommandozeilen-Werkzeugen logcat und die Android Debug Bridge (ADB) benötigt. Die eigentliche Logging-Arbeit übernimmt hierbei das logcat-Tool, welches dazu aber zuerst über die ADB angesteuert werden muss.

Die ADB haben wir bereits in einer vorherigen Lektion kennengelernt. Sie ist für die Kommunikation zwischen dem Entwicklungssystem und den angeschlossenen Android Geräten zuständig. Das Tool logcat ist für das Auslesen der Ringpuffer der Android Geräte verantwortlich. Es leitet deren Inhalte direkt an die Kommandozeile weiter. Dazu muss logcat aber über die ADB mit den Android Geräten verbunden sein.

Das Logging-Werkzeug logcat liest alle Log-Meldungen aus. Dies sind sowohl sämtliche Meldungen des Android Systems, als auch die Log-Meldungen der eigenen Android Anwendung. Außerdem kann mit logcat der Stack Trace ausgelesen werden, welcher über die Fehlerursache bei einem Absturz der Android App informiert.

Da Logcat in Android Studio fest integriert ist, können Log-Meldungen komfortabel innerhalb der Entwicklungsumgebung betrachtet werden. Das Logging-Tool kann aber auch direkt über die Kommandozeile gestartet werden. Dazu muss in den Ordner platform-tools/ des Android SDK Verzeichnisses navigiert werden. Von dort kann logcat über die Android Debug Bridge mit dem Befehl „adb logcat“ gestartet werden.

logcat_kommandozeile_beispiel

Ausgeben von Log-Meldungen mit logcat über die Android Debug Bridge

In der oberen Abbildung ist eine typische Ausgabe von logcat zu sehen. Durch den Befehl „adb logcat“ (Markierung A) werden alle Log-Meldungen der Default-Ringpuffer (main, system und crash) des angeschlossenen Android Geräts auf der Kommandozeile des Entwicklungssystems ausgegeben.

1.2 Der Aufbau einer Log-Meldung in Android

In Android bestehen Log-Meldungen nicht nur aus einem reinen Ausgabetext, also ihrer eigentlichen Botschaft, sondern enthalten noch einige weitere sehr wichtige Bestandteile. Mit Hilfe dieser zusätzlichen Komponenten können Log-Meldungen sortiert, gruppiert und gefiltert werden. Was für das Überwachen der eigenen App sehr hilfreich ist.

Die folgenden Komponenten sind Bestandteil jeder Log-Meldung in Android:

  1. Zeitstempel – Der Zeitpunkt (Datum und Uhrzeit) an dem die Meldung erstellt wurde.
  2. PID und TIDPID steht für Process Identifier, TID für Thread Identifier. Besitzt der Prozess nur ein Thread, sind sie gleich.
  3. Packagenamen – Der vollqualifizierende Name des Packages in welchem die Meldung erzeugt wurde.
  4. Prioritätsstufe – Jede Meldung besitzt eine genau definierte Wichtigkeit. Es gibt 7 Prioritätsstufen.
  5. TAG – Ein beliebiger String, der über die Herkunft der Meldung informiert.
  6. Ausgabetext – Dieser enthält den eigentlichen Inhalt der Log-Meldung.

Welche Prioritätsstufe eine Log-Meldung besitzt wird durch einen Character-Wert exakt definiert. Insgesamt sind in Android die folgenden Prioritätsstufen auf diese Weise definiert:

  • V: Verbose (niedrigste Priorität)
  • D: Debug
  • I: Info
  • W: Warning
  • E: Error
  • F: Fatal
  • S: Silent (höchste Priorität, hier wird niemals etwas ausgegeben)

Die Reihenfolge, in welcher die Komponenten ausgegeben werden, ist abhängig von dem gewählten Ausgabeformat der Log-Meldung. Standardmäßig ist das Format auf threadtime eingestellt.

Datum Uhrzeit       PID  TID  Prioritätsstufe TAG:                     Ausgabetext
10-05 10:09:27.195  1916 5657 W               WallpaperManagerService: Cannot extract colors.

Das Ausgabeformat kann aber auch vom Android Gerät vorgegeben werden. Ist auf dem Entwicklungsgerät bspw. das Format brief eingestellt, werden die Log-Meldungen folgendermaßen ausgegeben:

Prioritätsstufe/TAG       ( PID ): Ausgabetext
W/WallpaperManagerService ( 1916): Cannot extract colors.

Die obere Log-Meldung hätte in diesem Fall eine Prioritätsstufe von W: Warning und als TAG WallpaperManagerService. Außerdem ist zu erkennen, das die Meldung von einem Prozess mit dem Process Identifier 1916 erstellt wurde. Die eigentliche Botschaft der Meldung ist „Cannot extract colors.“.

1.3 Mit logcat nur bestimmte Log-Meldungen anzeigen lassen

Standardmäßig werden über logcat sämtliche Log-Meldungen der drei Default-Ringpuffer des angeschlossenen Android Geräts ausgegeben. In dieser Flut an Ereignismeldungen geht natürlich schnell die Übersicht verloren.

Es ist daher sinnvoll die Menge der angezeigten Meldungen zu reduzieren und nur noch die relevanten Log-Meldungen auszugeben. Dafür bietet logcat die Möglichkeit mit bestimmten Filterausdrücken gezielt nach Log-Meldungen zu suchen und dabei die übrigen auszublenden.

Ein Filterausdruck besitzt hierbei folgendes Format: TAG:Prioritätsstufe

Mit dem TAG wird festgelegt, welchen TAG die auszugebenden Log-Meldungen besitzen müssen. Mit der Prioritätsstufe wird vorgegeben, welche Prioritätsstufe Log-Meldungen mit dem passenden TAG mindestens besitzen müssen, damit diese auch ausgegeben werden.

Bspw. werden mit folgendem Befehl nur Log-Meldungen, die einen bestimmten TAG besitzen, ausgegeben:

adb logcat WallpaperManagerService:d *:s

Durch den ersten Filterausdruck WallpaperManagerService:d werden alle Log-Meldungen mit dem TAG WallpaperManagerService der Prioritätsstufe d (debug) und höher angezeigt.

Durch den zweiten Filterausdruck *:s werden alle anderen Log-Meldungen geblockt, da nur Meldungen der Prioritätsstufe s (silent) angezeigt werden und keine solchen Meldungen existieren.

Die Ausgabe von logcat für den Befehl „adb logcat WallpaperManagerService:d *:s“ (Markierung B) ist in der unteren Abbildung dargestellt. Wie zu erkennen ist, werden nur Log-Meldungen mit dem TAG WallpaperManagerService ausgegeben. Alle anderen Meldungen werden durch den Filterausdruck *:s abgeblockt.

logcat_filterausdruck

Filtern von Log-Meldungen mit logcat

Durch Nutzen des Filterausdrucks *:s dienen die weiteren Filterausdrücke als eine Art Whitelist für die Log-Ausgaben. Der obere Filterbefehl kann somit wie folgt gedeutet werden: „Blockiere alle Log-Meldungen außer denen mit dem TAG WallpaperManagerService ab der Prioritätsstufe debug.“. Auf diese Weise kann sehr effektiv nach Log-Meldungen, die einen bestimmten TAG besitzen, gefiltert werden.

1.4 Eigene Log-Meldungen per Quellcode ausgeben

Für das Ausgeben von eigenen Log-Meldungen stellt das Android Framework die Klasse Log zur Verfügung. Mit Hilfe dieser Klasse können Log-Meldungen sehr einfach per Quellcode ausgegeben und anschließend in logcat betrachtet werden.

Die eigenen Log-Meldungen werden mittels der folgenden fünf statischen Methoden erzeugt und ausgegeben:

  • Log.v(String, String) – Für ausführliches (verbose) Protokollieren während der Entwicklungsphase.
  • Log.d(String, String) – Ist für die Ausgabe von Debug-Informationen (debug) vorgesehen.
  • Log.i(String, String) – Für wichtige Statusinformationen (information). Nur spärlich zu verwenden.
  • Log.w(String, String) – Für Warnungen (warning) über den Zustand der App.
  • Log.e(String, String) – Aufgetretene Fehler (error) werden hiermit gemeldet.

Die oben aufgeführten Log-Methoden sind nach Priorität sortiert. Die niedrigste Prioritätsstufe besitzen demnach verbose-Meldungen, die höchste error-Meldungen.

Jede der fünf Log-Methoden besitzt zwei Parameter vom Typ String. Dem ersten Parameter wird der Meldungs-TAG übergeben, der über die Herkunft der Meldung informiert und über den diese später identifiziert werden kann. Dem zweiten Parameter wird der Ausgabetext, also der eigentliche Meldungsinhalt, übergeben.

Mit folgendem Quelltext werden Log-Meldungen der fünf Prioritätsstufen erzeugt:

import android.util.Log;
...
private static final String LOG_TAG = MainActivity.class.getSimpleName();
...
Log.v(LOG_TAG, "Verbose     - Meldung.");
Log.d(LOG_TAG, "Debug       - Meldung.");
Log.i(LOG_TAG, "Information - Meldung.");
Log.w(LOG_TAG, "Warning     - Meldung.");
Log.e(LOG_TAG, "Error       - Meldung.");

In Zeile 1 wird die Log-Klasse aus dem android.util Package importiert. Anschließend wird in Zeile 3 der Klassenname in der Konstante TAG abgespeichert. In den Zeilen 5 bis 9 werden die Log-Meldungen erzeugt. Sie besitzen den gleichen TAG, unterscheiden sich jedoch in ihren Prioritätsstufen.

Hinweis: In der Praxis ist es sehr nützlich in jeder eigenen Klasse eine TAG-Konstante anzulegen, welche den Namen der Klasse enthält. Diese Konstante wird dann als erster Parameter der jeweiligen Log-Methode übergeben. Dadurch kann später über den Klassennamen gezielt nach den jeweiligen Log-Meldungen mit logcat gesucht werden.

Die fünf Log-Meldung werden dann von logcat im brief Ausgabeformat folgendermaßen ausgegeben:

V/MainActivity    ( 753): Verbose     - Meldung.
D/MainActivity    ( 753): Debug       - Meldung.
I/MainActivity    ( 753): Information - Meldung.
W/MainActivity    ( 753): Warning     - Meldung.
E/MainActivity    ( 753): Error       - Meldung.

Der Einsatz von Log-Meldungen sollte sehr bedacht erfolgen. So sollten keine verbose-Meldungen in der finalen App enthalten sein. Diese sollten nur während der Entwicklungsphase verwendet und anschließend aus dem Quellcode entfernt werden. Debug-Logs werden zwar kompiliert, aber zur Laufzeit automatisch entfernt. Daher stellen sie einen Sonderfall dar. Alle anderen Log-Meldungen (information, warning und error) bleiben in der App immer enthalten und sollten daher nur wenn unbedingt nötig eingesetzt werden.

1.5 Betrachten von Log-Meldungen in Android Studio

Die Log-Meldungen können auch direkt in Android Studio betrachtet werden. Dafür stellt die Entwicklungsumgebung die folgenden Tools zur Verfügung:

  • Terminal Tool Window – Das Terminal ist eine in Android Studio integrierte Kommandozeile, über die gezielt nach Log-Meldungen gefiltert werden kann. Das Auslesen der Meldung wird von logcat übernommen, das über die Android Debug Bridge angesteuert wird.

  • Logcat Tool Window – Das Logging-Tool logcat ist in Android Studio als eigenes Tool Window integriert und kann über grafische Bedienelemente gesteuert werden. Die Darstellung der Log-Meldungen kann sogar an die eigenen Bedürfnisse angepasst werden.

  • Android Device Monitor – Der Android Device Monitor wurde in einem eigenen Fenster ausgeführt und war mit dem Dalvik Debug Monitor Server (DDMS) verzahnt. Über den DDMS konnten neben Log-Meldungen noch viele weitere Debugging-Informationen analysiert werden, wie bspw. der Speicherbedarf der App und Netzwerkzugriffe. Mit Erscheinen von Android Studio 3.2 wurde der Android Device Monitor aus der Entwicklungsumgebung entfernt.

Wir werden im Laufe dieser Lektion die ersten beiden Logging-Werkzeuge kennenlernen und mit ihnen unsere eigenen Log-Meldungen auslesen und betrachten. Doch damit unsere App eigene Log-Meldungen ausgibt, müssen wir vorher noch einige Änderungen an ihrem Quellcode vornehmen. Dies werden wir im nächsten Abschnitt ausführen.

2. Mit unserer Android App eigene Log-Meldungen ausgeben

Mit unserer Android App möchten wir nun mehrere Log-Meldungen zu Testzwecken ausgeben. Dazu müssen wir einige Änderungen am Quellcode vornehmen. Pro Prioritätsstufe soll jeweils eine Log-Meldung erzeugt werden. Zudem sollen die Meldungen direkt beim Starten unserer App ausgegeben werden.

Um die notwendigen Änderungen durchzuführen, öffnen wir die Klassendatei MainActivity.java im Editor von Android Studio. Dazu klicken wir doppelt auf ihren Dateinamen im Project Tool Window. Die Klassendatei befindet sich im Package-Ordner de.codeyourapp.zitate unseres Projekts.

Den bisherigen Quellcode lassen wir zu großen Teilen bestehen und nehmen nur einige kleine Änderungen darin vor. Der bereits überarbeitet Quellcode der MainActivity.java ist unten aufgeführt. Die neu eingefügten Zeilen sind grau markiert:

MainActivity.java

package de.codeyourapp.zitate;
 
import androidx.appcompat.app.AppCompatActivity;
import android.os.Bundle;
//import android.widget.TextView;
 
import android.util.Log;
 
public class MainActivity extends AppCompatActivity {
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
 
        String logTag = MainActivity.class.getSimpleName();
 
        Log.v(logTag, "Verbose     - Meldung.");
        Log.d(logTag, "Debug       - Meldung.");
        Log.i(logTag, "Information - Meldung.");
        Log.w(logTag, "Warning     - Meldung.");
        Log.e(logTag, "Error       - Meldung.");
 
        //TextView welcomeMessageTV = new TextView(this);
        //welcomeMessageTV.setText("Hello CodeYourApp World!");
        //setContentView(welcomeMessageTV);
 
        setContentView(R.layout.activity_main);
    }
}

In Zeile 7 führen wir den Import der Log-Klasse aus dem Package android.util durch. Dadurch können wir komfortabler auf die Klasse zugreifen und müssen nicht den vollqualifizierenden Klassennamen (android.util.Log) verwenden.

In Zeile 15 legen wir die Variable logTag an, in der wir den Namen unserer Klasse (MainActivity) speichern. Anstelle den Klassennamen mit eine Literal fest vorzugeben, fragen wir ihn mit der Methode getSimpleName() ab. Dies ist nützlich, falls wir später den Namen der Klasse ändern. Dann würde uns vom Compiler ein Fehler in Zeile 15 signalisiert werden und wir würden dadurch nicht vergessen, die notwendige Anpassung vorzunehmen.

In den Zeilen 17 bis 21 lassen wir mit Hilfe der statischen Log-Methoden fünf Meldungen erzeugen und ausgeben. Jeder Methode übergeben wir zwei Argumente von Typ String. Das erste Argument ist der TAG, der Auskunft über die Herkunft der Meldung gibt, das zweite enthält die eigentliche Botschaft. Die Prioritätsstufe der jeweiligen Meldung ergibt sich aus dem Methodennamen (v = verbose, d = debug, i = information, w = warning, e = error).

In Android Studio sollte die MainActivity.java Klassendatei nun wie folgt aussehen:

mainactivity_log_methods

Die Klassendatei MainActivity.java mit den vorgenommenen Änderungen

Mit der ersten blauen Markierung (A) ist die Import-Anweisung der Log-Klasse gekennzeichnet. Sie darf auf keinen Fall vergessen werden, da wir sonst nicht in Kurzform auf die Log-Methoden zugreifen können.

Weiter unten erfolgen die Aufrufe der Log-Methoden (Markierung B), durch sie werden die fünf Log-Meldungen erzeugt. Die Aufrufe finden in der onCreate() Methode der MainActivity-Klasse statt. Die onCreate() Methode wird automatisch beim Erzeugen der Activity vom Android System aufgerufen. Somit werden die fünf Log-Meldungen bei jedem Start unserer App ausgegeben.

2.1 Ausführen unserer App auf dem Android Virtual Device

Jetzt haben wir alle notwendigen Änderungen an den Projektdateien vorgenommen. Unsere App gibt von nun an bei jedem Start fünf Log-Meldungen aus.

Um die ausgegebenen Log-Meldungen zu analysieren, werden wir unsere App auf dem in dieser Lektion angelegten Android Virtual Device im Emulator ausführen lassen. Dadurch sollten bei jedem Leser die Log-Meldungen in dem gleichen Ausgabeformat zu sehen sein.

Unsere App starten wir dazu wie gewohnt über den Run > Run 'app' Menüeintrag, den wir über die obere Menüleiste erreichen.

Hinweis: Das Emulator-Fenster mit dem darin laufenden Android Virtual Device muss für die nächsten Arbeitsschritte geöffnet bleiben. Solltet ihr es aus Versehen geschlossen haben, muss Abschnitt 2.1 erneut ausgeführt werden.

3. Log-Meldungen im Terminal Tool Window betrachten

Wir werden nun die Log-Meldungen unserer App im Terminal Tool Window von Android Studio betrachten. Damit dies möglich ist, muss unsere Android App noch auf dem AVD im Emulator ausgeführt werden, d.h. das Emulator-Fenster sollte noch geöffnet sein.

Die App gibt jetzt direkt nach dem Starten fünf Log-Meldungen aus. Diese Meldungen werden aber nicht auf dem Display des Android Geräts angezeigt, sondern im Hintergrund von dem Android Logging System behandelt. Um unsere Log-Meldungen zu betrachten, werden wir das Logging-Werkzeug logcat über die Android Debug Bridge (ADB) ansteuern und mit dessen Hilfe die Log-Buffer des Android Systems auslesen.

Nun öffnen wir als Erstes das Terminal Tool Window von Android Studio. Dazu führen wir die folgenden Schritte aus:

  1. Mit der Maus auf den Menüeintrag View in der oberen Menüleiste klicken.
  2. Anschließend auf Tool Windows klicken.
  3. Und schließlich auf Terminal klicken, um die integrierte Kommandozeile zu öffnen.
terminal_tool_window_menu

Über die obere Menüleiste das Terminal Tool Window öffnen

Das Terminal Tool Window klappt anschließend am unteren Bildschirmrand nach oben auf. Um das Terminal Tool Window später schnell zu schließen und wieder aufzuklappen, kann auf den Terminal-Tab geklickt werden, siehe Markierung A in der unteren Abbildung.

Damit wir logcat über die Android Debug Bridge (ADB) ansteuern können, werden wir als Nächstes in den platform-tools/ Ordner des Android SDK Verzeichnisses navigieren (Markierung B):

terminal_tool_window

Das Terminal Tool Window, die integrierte Kommandozeile von Android Studio

Das Android SDK Verzeichnis liegt bei euch wahrscheinlich an einer anderen Stelle. Der Speicherort ist abhängig von dem bei der Installation von Android Studio gewählten Verzeichnis. Ihr könnt euch den Pfad zum Android SDK Verzeichnis über den Menüeintrag File > Project Structure… > Android SDK location anzeigen lassen.

Hinweis: Das Emulator-Fenster mit dem darin laufenden Android Virtual Device muss für die nächsten Arbeitsschritte geöffnet bleiben. Zudem muss in dem AVD unsere eigene App ausgeführt werden. Sollte dies nicht der Fall sein, muss Abschnitt 2.1 erneut ausgeführt werden.

In dem platform-tools/ Ordner befindet sich die ausführbare Datei adb.exe. Wir werden mit ihrer Hilfe jetzt eine Verbindung zu dem im Emulator laufenden AVD aufbauen und die Log-Meldungen unserer Android App auslesen.

Dazu werden wir den folgenden ADB-Befehl im Terminal Tool Window ausführen lassen:

adb logcat MainActivity:v *:s

Dabei werden durch:

  • den Parameter MainActivity:v alle Log-Meldungen mit dem TAG MainActivity der Prioritätsstufe v (verbose) und höher angezeigt.

  • den Parameter *:s alle anderen Log-Meldungen blockiert, da nur Meldungen der Priorität s (silent) angezeigt werden, von denen keine existieren.

Wenn wir nun den ADB-Befehl adb logcat MainActivity:v *:s (Markierung C) im Terminal Tool Window eingeben, werden uns die folgende Log-Meldungen (Markierung D) von logcat ausgegeben:

log_meldungen_terminal

Ausgeben unserer Log-Meldungen per ADB-Befehl im Terminal Tool Window

Hinweis: Falls die fünf Log-Meldungen nicht ausgegeben werden, ist es notwendig, die App nochmals zu starten. Dazu muss die App auf dem AVD mittels Back-Button beendet und über das Alle Apps Menü erneut gestartet werden. Beim erneuten Start der App werden die Log-Meldungen nochmals ausgegeben.

Die fünf Log-Meldungen werden in dem Ausgabeformat threadtime dargestellt. Dies ist das in logcat voreingestellte Standardformat für Log-Meldungen. Es besteht aus folgenden Komponenten:

Datum Uhrzeit       PID   TID   Prioritätsstufe TAG:           Ausgabetext
01-31 11:36:35:868  7122  7122  I               MainActivity:  Information - Meldung.

Wem dieses Format zu detailliert ist, kann ein weniger umfangreiches Ausgabeformat für die Log-Meldungen festlegen. Mit dem ADB-Befehl adb logcat MainActivity:v *:s -v brief (Markierung E) werden die Meldungen unserer App in Kurzform (Markierung F) dargestellt:

log_meldungen_terminal_brief

Ausgeben unserer Log-Meldungen per ADB-Befehl im Kurzformat

Die Log-Meldungen im brief Ausgabeformat besitzen folgende Komponenten:

Prioritätsstufe/TAG ( PID):   Ausgabetext
I/MainActivity      ( 15870): Information - Meldung.

Wir können nun unsere eigenen Log-Meldungen im Terminal Tool Window von Android Studio betrachten und somit den Zustand unserer App überwachen. Die Meldungen im Terminal zu analysieren, ist jedoch nicht sehr komfortabel. Daher werden wir uns im nächsten Abschnitt dem Logcat Tool Window widmen, einem weiteren integrierten Logging-Tool von Android Studio.

4. Log-Meldungen im Logcat Tool Window betrachten

Mit dem Logcat Tool Window können Log-Meldungen sehr komfortabel und effektiv in Android Studio betrachtet werden. In ihm ist das Logging-Tool logcat bereits integriert und kann intuitiv über die grafischen Bedienelemente gesteuert werden. Die Log-Meldungen werden in Echtzeit angezeigt. Auch der Log-Verlauf wird abgespeichert, so dass schnell nach älteren Meldungen gesucht werden kann.

Um die Menge der angezeigten Log-Meldungen einzugrenzen, können Filter erstellt werden. Mit Hilfe derer nur Meldungen bestimmter Prioritätsstufen, TAGs und Process IDs ausgegeben werden. Zudem kann exakt vorgegeben werden, welche Komponenten der Log-Meldungen dargestellt werden sollen.

Neben dem Anzeigen von Log-Meldungen erfüllt das Logcat Tool Window aber noch einen weiteren Zweck. Er zeigt den Stack Trace (ausführliche Fehlermeldung) im Falle eines App-Absturzes an, welcher zu der Fehlerstelle im Quellcode führt. Dies ist für das Debugging von sehr großer Bedeutung.

Hinweis: Das Emulator-Fenster mit dem darin laufenden Android Virtual Device muss für die nächsten Arbeitsschritte geöffnet bleiben. Zudem muss in dem AVD unsere eigene App ausgeführt werden. Sollte dies nicht der Fall sein, muss Abschnitt 2.1 erneut ausgeführt werden.

Nun möchten wir das Logcat Tool Window öffnen und darin die Log-Meldungen unserer App betrachten. Dazu führen wir die folgenden Schritte aus:

  1. Mit der Maus auf den Menüeintrag View in der oberen Menüleiste klicken.
  2. Anschließend auf Tool Windows klicken.
  3. Und schließlich auf Logcat klicken.
logcat_tool_window_menu

Über die obere Menüleiste das Logcat Tool Window öffnen

Das Logcat Tool Window klappt anschließend am unteren Bildschirmrand nach oben auf. Es ist in der unteren Abbildung dargestellt. Mit einem Klick auf den Logcat-Tab (Markierung A) kann es bei Bedarf schnell auf und wieder zu geklappt werden.

logcat_tool_window_open

Das Logcat Tool Window von Android Studio

Im Moment werden aber noch zu viele Meldungen im Logcat Tool Window ausgegeben. Es ist daher nötig, die Anzahl der angezeigten Log-Meldungen zu reduzieren. Für diese Aufgabe stellt uns das Logcat Tool Window einige sehr nützliche Funktion zur Verfügung.

Wir möchten uns nun alle Log-Meldungen anzeigen lassen, die von unserer Anwendung aus erzeugt werden. Dies beinhaltet sowohl die in unserem Quellcode erzeugten Meldungen als auch die Meldungen der mitgenutzten Android Klassen.

Um alle Log-Meldungen unserer Android App anzuzeigen, führen wir die folgenden Schritte aus:

An dieser Stelle endet der freie Inhalt dieser Lektion. Wir hoffen, sie hat dir bis hierher gefallen! Du kannst sie im geschützten Bereich von ProgrammierenLernenHQ fortsetzen, in welchem sich alle Lektionen unserer Android Online-Kurse befinden.

Unsere Android Kurse bestehen aus insgesamt 43 großen Lektionen und sind unterteilt in 13 frei zugängliche und 30 Premium-Lektionen. Die Premium-Lektionen befinden sich in dem geschützten Bereich und sind nur für Käufer unserer Android Online-Kurse zugänglich.

plhq_teaser_hbox_gelb_fotolia_RA Studio_46292813 An dieser Stelle endet der freie Inhalt dieser Lektion. Wir hoffen, sie hat dir bis hierher gefallen! Du kannst sie durch Kauf unseres Android Online-Kurs Gesamtpakets freischalten.

In unserem Android Online-Kurs Gesamtpaket befinden sich 43 große Lektionen, in denen wir dir schrittweise zeigen, wie voll funktionstüchtige Android Apps programmiert werden.

Diese Lektion ist Teil unserer Android Kurse. Insgesamt sind unsere Online-Kurse unterteilt in 13 frei zugängliche und 30 Premium-Lektionen.

Die Premium-Lektionen befinden sich in dem geschützten Bereich und sind nur für Käufer des Android Online-Kurs Gesamtpakets zugänglich.



Welche Inhalte befinden sich im Android Online-Kurs Gesamtpaket?

  • Das Gesamtpaket enthält alle Android Online-Kurse von ProgrammierenLernenHQ.
  • Im Paket enthalten ist unser großer Android Apps Programmieren Online-Kurs. Dieser besteht aus 35 großen Lektionen und ist als Einstiegskurs konzipiert worden. Die Grundlagen der Android App Entwicklung praxisnah und verständlich zu lehren, ist das Hauptziel des Android Apps Programmieren Kurses.
  • Im Paket enthalten ist auch unser SQLite Datenbank App Programmieren Online-Kurs. Dieser besteht aus 8 großen Lektionen und ist als weiterführender Kurs konzipiert worden. Der Kurs schließt an unseren Android Apps Programmieren Hauptkurs an und widmet sich dem speziellen Thema der SQLite Datenbanken.
  • Durch den Kauf erhältst du unbegrenzten Zugang zu all unseren Android Online-Kursen. Wir werden in Zukunft weitere Android Kurse hinzufügen. Auch auf alle zukünftigen Kurse erhältst du vollen Zugriff.

Wir hoffen, Dich bald als neuen Kursteilnehmer unserer Android Online-Kurse begrüßen zu dürfen!

Einmal kaufen und dadurch zeitlich unbegrenzten Zugriff auf alle Inhalte unserer Android Online-Kurse erhalten.






Comments 35

  1. Hallo Chris,
    auch erstmal danke für die ausführliche Anleitung. Ich habe auch ein Problem mit den log Dateien. Mit meinem alten Huawei (Android 4.4.2) habe ich mir im Terminal (Mac) diese verbose, debug.. Meldungen ausspucken lassen können, nachdem ich auf dem Handy *#*#2846579#*#* gewählt habe und log auf on gestellt habe.

    Aber auf meinem LG (Android 7) spuckt mir das Terminal nichts aus. Ein Fehler im Logcat Fenster von Android Studio ist:
    Neither user 10223 nor current process has android.permission.READ_PHONE_STATE.

    Ich habe gelesen, dass seit Android 6.0 gewisse permissions gebraucht werden.
    Also habe ich in mein Manifest mal

    hinzugefügt, aber das reicht anscheinend nicht.
    Ich habe noch viel rumgesucht und auch Code probiert, aber leider ohne Erfolg, da ich auch noch nicht sehr tief in der Thematik stecke. Kannst du mir da weiterhelfen, oder das Tutorial um diese permissions erweitern, da das ja wahrscheinlich alle betrifft, die mit Android 6.0 oder höher arbeiten?

    Vielen Dank,
    Max

    1. Post
      Author

      Hallo Max,

      die Log-Meldungen sollten auch ohne Permissions ausgegeben werden. Sie werden ja über die Android Debug Bridge empfangen. Jedoch scheint es bei manchen Smartphones und Tablets zu Problemen mit den Log-Meldungen zu kommen. Ich selbst hatte diese Art von Problemen auf meinen Testgeräten noch nicht.

      Hast du die App auch einmal auf einem Android Virtual Device im Emulator laufen lassen?

      Viele Grüße, Chris

  2. Hallo,

    vielen Dank für Ihre Hilfe. Für Anfänger ist das sehr hilfreich.
    Ich habe ein Problem, und zwar unter „Tool“ gibt es keinen „Android“ Eintrag und DDMS kann ich nirgendwo finden.
    Ich habe die Version 3.1.1. Ich habe im Internet recherchiert aber nichts gefunden.
    In der SDK Manager sieht so aus, wie hier in der Lektion 1.
    Vielen Dank im Voraus.

    Viele Grüße
    Ion

    1. Post
      Author

      Hallo Ion,

      danke für dein Lob!

      Die Benutzeroberfläche von Android Studio hat sich seit dem Erstellen dieses Tutorials teilweise verändert. Das Android-Tool wird nun als Logcat Tool Window in Android Studio geführt. Und DDMS wird nicht mehr weitergepflegt. Ich werde dieses Tutorial demnächst aktualisieren und die Screenshots an die neue GUI von Android Studio anpassen.

      Viele Grüße, Chris

  3. Servus Chris!

    Wirklich tolles Tutorial hast du erstellt. Man sieht, dass ziemlich viel Arbeit drin steckt und erst bereitet wirklich viel Freude.

    Meine Nachfrage zur DDMS: Auf Mac OS X muss ich dazu eine ältere Flash Version (6.0) installieren. Gibt es eine entsprechende „neue Version“ der DDMS, die mit dem neuem Flash auskommt? Die Maske finde ich grundsätzlich besser als LogCat. Und da dieses Tutorial doch auf einer älteren Version von Android Studio beruht, hat sich vielleicht etwas neues ergeben?

    Merci für die Antwort und nochmals besten Dank für das Tutorial!

    Beste Grüße,
    Sebastian

  4. Hallo

    Erstmal, danke für dieses Tutorial.
    Ich habe folgendes Problem:
    Bei Schritt 5.1 werden bei meinem Terminal nicht 5 sondern 20 Log-Meldungen.
    Ich hoffe ihr könnt mir hierbei helfen!

    MfG,
    Leonhard

    1. Ich habe das Problem gefunden: ich hatte mehrere Projekte offen dadurch wurden mehr log-Meldungen in der Kommandozeile angezeigt, allerdings tritt beim DDMS das gleiche Problem ein, wenn ich pid:12345 eingebe zeigt es mir mehr an als erwünscht. Wenn ich tag:AktienlisteFragment werden mir 5 angezeigt. Diesmal habe ich nur dieses eine Projekt offen.

  5. Wirklich ein sehr gutes Tutorial und ich hoffe mir wird in den folgenden Lektionen noch alles klar .
    Noch ein kleiner Hinweis : bei mir wurde nach der umbenennung automatisch die import bezeichnung geändert daher bitte mal mit neuer version wiederholen.und wenn es alternative möglichkeiten gibt diese auch direkt mit angeben denn mit dem terminal das ist ja eh (für mich unnötig) und mit dem Device Monitor geht es auch viel einfacher

    1. Post
      Author
  6. Hi

    also bei mir hat das ADO gut funktioniert der DDMS aber gar nicht.
    ich bekomme beim Klick auf „Tools -> Android -> Android Device Monitor“ immer die Meldung
    An error has occurred. See the log file.
    Und im Log steht halt das:

    java.io.IOException: The folder "C:\Users\User%20Name\.android\monitor-workspace\.metadata" is read-only.
    	at org.eclipse.core.runtime.internal.adaptor.BasicLocation.lock(BasicLocation.java:206)
    

    Nun hab ich in dem besagten Ordner nachgesehen und er hatte recht der Ordner .android war schreibgeschützt. Hab ich also den Schreibschutz entfernt. Hat aber nichts geändert…
    Dann ist mir aufgefallen: ordner monitor-workspace gibt es bei mir gar nicht.
    hab ich ihn per hand erzeugt .. immer noch selbe meldung.
    .metadata konnte ich nicht erzeugen das lässt windows nicht zu ..
    wie komme ich hier weiter?

    mfg Kala

    1. Post
      Author
  7. Hallo

    Ersteinmal vielen Dank für diese tolle Tutorial!
    Jetzt aber zu meiner Frage: Ich bekomme die Meldungen im Terminal angezeigt, aber nicht im DDMS. Das DDMS zeigt sie aber weder bei einem angeschlossenen Gerät, noch bei den Emulatoren an. Wie geschrieben, im Terminal tauchen Sie aber auf …

    Viele Grüße
    Asta

    1. Post
      Author

      Hallo Asta,

      schwierig zu sagen, woran es liegt. Ich hatte dieses Problem bisher noch nicht auf meinen Entwicklungssystemen. Vielleicht hatten andere Leser bereits ähnliche Probleme und können Tipps geben?

      Viele Grüße, Chris

  8. Hallo Chris, leider erscheint auf meinem Huawei (4.3) das Options-Menu (Overflow) nicht, während es auf dem Nexus erscheint. Kann das an der Android-Version liegen ? Ich bin ziemlich sicher, dass ich bei der Eingabe nichts weggelassen habe .
    Vielen Dank für eine Antwort !

    1. Post
      Author

      Hallo Norbert,

      es hatten schon einige Leser ein Problem mit der Action Bar und dem Options Menu. Woran es liegt weiß ich momentan leider noch nicht. Manchmal wurden die Menüeinträge des Options Menu angezeigt, wenn der (Hardware) Menü-Button auf dem Android Gerät gedrückt wird. Also nicht der Back-Button, sondern der Button links neben dem Home-Button.

      Wenn Du möchtest, kann ich mir Deinen Quellcode mal in Android Studio ansehen und testen, ob bei mir das Menü angezeigt wird. Dazu würde ich die Projektdateien als ZIP per E-Mail benötigen.

      Ich habe außerdem bei StackOverflow einige Tipps finden können. Dort wird empfohlen das App-Theme zu ändern. Siehe folgender Link:

      action bar does not show

      Viele Grüße, Chris

    2. Hallo Chris, die Änderung des Themes bewirkt die Beendigung der App auf meinem Gerät !
      Grüße ! Norbert

    3. Post
      Author

      Hallo Norbert,

      Ohh. Das hört sich nicht gut an. Das ist ein grundsätzliches Problem bei der Android Programmierung, dass die App zu so vielen verschiedenen Geräten kompatibel sein sollte und man sie nur auf einigen wenigen testen kann.

      Viele Grüße, Chris

  9. Auch von mir erst mal ein großes Lob. Das Tutorial ist wirklich sehr gut und verständlich verfasst.

    Zu dem Problem mit den nicht erscheinenden Log-Meldungen, was ich anfänglich auch hatte: Bei mir hat es funktioniert, nachdem ich
    1. App auf mein Smartphone übertragen hatte
    2. Erscheinende App geschlossen hatte
    3. App vom Smartphone neu starten und dann schließen

    Anschließend erschienen die Meldungen, zumindest über DDMS.

    1. Post
      Author

      Hallo Wolfgang,

      danke für Deinen sehr hilfreichen Hinweis. Er wird bestimmt einigen Lesern weiterhelfen.

      Viele Grüße, Chris

    2. Hallo,

      der Rat vom Wolfgang hat mein Problem gelöst mit dem nichtanzeigen der Log-Meldungen.
      Vielen Dank dafür.

      Außerdem bis hier hin ein super Tutorial, ich finde das gut wie die verschieden Schichten einer App, behandelt werden. Hoffe es geht so weiter gut voran.

      Viele Grüße
      Denis

    3. Post
      Author

      Hallo Dennis,

      danke für’s Lob! Ja das Tutorial geht in diesem Stil weiter. Schicht für Schicht, Stück für Stück wird die Android App erweitert.

      Viele Grüße, Chris

  10. Wieder einmal ein sehr schönes Tutorial für Anfänger!

    Genauso wie im vorherigen Kapitel wird die App hier zuerst auf dem AVD und anschließend auf einem realen Gerät getestet. Leider braucht die AVD sehr lange bei mir und ich frage mich, ob ich die Funktion „Run ‚app'“ für AVD und reales Gerät kurz nacheinander starten kann. Kann Android Studio sowas gleichzeitig verwalten oder sollte man sowas unterlassen, damit das Programm nicht „durcheinander“ kommt?

    Bislang habe ich die AVD abgewartet, alles angeschaut, AVD geschlossen und dann erst die App auf dem realen Gerät ausgeführt.

    Viele Grüße,
    Marvin

    1. Post
      Author

      Hallo Marvin,

      keine Angst… Android Studio kommt dadurch nicht „durcheinander“.

      Es ist auch möglich die eigene App gleichzeitig auf das AVD und das reale Gerät aufzuspielen über die „Run App“-Funktion. Dazu einfach mit der Shift-Taste beide Devices auswählen.

      Viele Grüße, Chris

  11. Also erstmal was sehr angebracht ist
    Ein großes Lob und vielen dank für diese Anleitung. Welche wirklich gut und sehr ausführlich für Anfänger geschrieben ist.

    Folgendes Problem habe ich an der Stelle 5.2
    Sobald ich auf Dalvik Debug Monitor Servers (DDMS) drücke
    Bekomme ich in einem externen monitor die Fehlermeldung : An error has occurred. See the log File
    c:\Android\sdk1\tools\lib\monitor -x86_64\configuration\1448369689367.log

    Als blutiger Anfänger kann ich damit nicht wirklich viel anfangen und würde nur raten ob es vielleicht mit dem Intel HAXM Treiber zu tun hat und man diese fehler vielleicht dann umgehen kann.
    Werde diesen Teil somit dann erstenmal überspringen.
    Veleicht ist dieser Fehler dir ja bekannt oder/und du weißt eine Lösung dafür.

    Vielen lieben Dank

    1. Post
      Author

      Hallo Mark,

      danke für die lobenden Worte!

      Die genaue Fehlermeldung steht in dem Log-File drin. So ist es nicht möglich zu sagen, welches Problem der DDMS genau hat.

      Für das Tutorial ist der DDMS aber nicht zwingend erforderlich. Du kannst die Log-Meldungen auch über die Konsole verfolgen, das geht genauso gut. Für komplexe Analysen, bspw. Speicherbedarf oder Netzwerkaktivitäten, ist dann der DDMS richtig. Im Tutorial machen wir so etwas aber nicht. Daher reicht die Konsole.

      Viele Grüße, Chris

  12. Hallo,

    weiterhin erhalte ich keine Log-Meldungen. Das Problem vermute ich eher beim Quellcode bzw. einer Einstellung bei Android Studio. Das Smartphone schließe ich aus, schließlich erhalte ich keine Logmeldungen, ob das Smartphone angeschlossen ist oder nicht. Vielleicht hat doch jemand noch einen Tipp für mich?

    Viele Grüße,
    Daniela

  13. Hallo,

    bin bei Kapitel 5.1 hängen geblieben. Wenn ich alles in die Kommandozeile eingegen habe, erscheint folgende Meldung:

    Note: log switch off, only log_main and log_events will have logs!
    ——— beginning of /dev/log/main

    und hier stoppt es dann, die folgende Zeile
    ——— beginning of /dev/log/main
    bzw. die gewünschte Ausgabe erscheinen nicht.

    Wie kann ich log switch auf „on“ stellen?

    Danke im Voraus, tolle Webseite übrigens, und viele Grüße
    Daniela

    1. Bin trotzdem mal weiter zu 5.2 gegangen und habe logs mithilfe des DDMS gesucht, erhielt aber erwartungsgemäß keine Werte, weder über die Suche per „pid:“ noch „tag:“.

      Ist es eine Einstellung an meinem angeschlossenen Android-Gerät selbst? Bei stackoverflow bzw. google habe ich bisher leider auch keine Lösung gefunden, um log-Daten anzeigen zu lassen.
      Wäre super, wenn mir jemand noch weiterhelfen könnte.

      Ich arbeite übrigens mit Android 23 als Zielsystem. Bisher konnte ich deinem Kurs dennoch ohne Probleme folgen.

    2. Post
      Author

      Hallo Daniela,

      ich hatte bisher noch keine Probleme mit den Log-Meldungen, von daher fehlt mir leider die Erfahrung.

      Kann vielleicht ein Leser aushelfen, der schon ähnliche Probleme hatte?

      Viele Grüße, Chris

    3. Versuchs einfach mal über den Android Monitor (Alt+6 oder unten links in der Leiste) und, dann den Tag suchen ohne das „tag:“ davor.
      Ich hatte auch erst Probleme bei dem im Terminal da weiß ich leider nicht mehr wie ich das Problem behoben habe.
      Ich hoffe ich konnte helfen.

      LG
      HkVK

  14. Pingback: Android Tutorial: Daten von einer Webseite abfragen in Android

  15. Pingback: Android Tutorial: Options Menu und Action Bar in Android

  16. Pingback: Android Tutorial: Daten mit einem Listview anzeigen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.