© Excellent backgrounds/Shutterstock.com
Android-Logging-Framework

Das kleine Logging-1x1


Das Android-Logging-Framework [1] ist denkbar einfach aufgebaut. Kein Wunder also, dass es von Entwicklern gerne als Debugging-Werkzeug genutzt wird. Dabei gehen die Möglichkeiten des Frameworks deutlich darüber hinaus und bringen ganz nebenbei das eine oder andere Sicherheitsrisiko mit sich.

Wahrscheinlich kennt jeder Android-Entwickler die Klasse Log aus dem android.util Package. Mithilfe ihrer statischen Methoden

e(...) // ERROR w(...) // WARNING i(...) // INFOR d(...) // DEBUG v(...) // VERBOSE

lassen sich Logausgaben für die verschiedenen Loglevel erzeugen. Als Parameter erwarten alle fünf Methoden ein TAG vom Typ String sowie die eigentliche Log-Message. Optional kann zusätzlich ein weiterer Parameter vom Typ Throwable übergeben werden. Als TAG verwendet man in der Regel einen eindeutigen Bezeichner für die gesamte App oder alternativ für jede Klasse. Mithilfe des TAGs lassen sich später die vielen Logmeldungen gezielt filtern.

Dass die Entwickler des Android-Logging-Frameworks nicht frei von Humor sind, zeigen die in der API-Version 2.2 hinzugefügten, eher unbekannten Methoden:

wtf (String tag, Throwable tr) // ERROR wtf(String tag, String message) // WARNING wtf(String tag, String message, Throawable tr) // WARNING

Damit an dieser Stelle keine Missverständnisse aufkommen: WTF steht angeblich für „what a terrible failure“ und dient dem Reporten von Situationen, die eigentlich nie auftreten dürften. Geloggt wird das Ganze mit dem Loglevel ASSERT und dem Call-Stack. Je nach Systemkonfiguration führt ein wtf-Log dabei automatisch zur Beendigung der App inkl. Fehlerdialog.

LogCat

Die geloggten Informationen einer App landen in verschiedenen, rollierenden Log-Buffern direkt auf dem Device und können dort via

adb logcat –b [BUFFERNAME]

ausgelesen und über verschiedene optionale Parameter gefiltert werden. Als Buffer stehen main (default) und system (Android-System) sowie radio (Telefonie) und event (eventbezogene Nachrichten) zur Verfügung.

Bis zur Version 4.1 waren die Logeinträge jeder beliebigen App auch für alle anderen Apps zugänglich, was ein erhebliches Sicherheitsrisiko darstellte und in der Praxis zu echten Problemen geführt hat. Ein einfacher Aufruf von

Runtime.getRuntime().exec("logcat")

sowie gesetzte READ_LOGS Permissions innerhalb des eigenen Manifests und schon war ein Zugriff möglich. Aber auch in den Versionen 4.1+ gibt es den einen oder anderen Weg, sich Informationen anderer Apps aus dem Log zu besorgen [2]. Genau aus diesem Grund gib...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang