Informationen zum Logging

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

In diesem Artikel werden Protokollierungsverfahren, einschließlich Protokollstandards, Richtlinien für Ebenen, Klassen, Zwecke und Multistack-Schätzungen behandelt.

Protokollstandards

Die Protokollierung unter Android ist aufgrund der verschiedenen Standards, die in logcat kombiniert werden, komplex. Die wichtigsten Standards werden unten beschrieben:

Abbildung 1:Standards für die Protokollebene

Obwohl die Struktur der einzelnen Standards ähnlich ist, unterscheiden sie sich in der Detaillierung. Die ungefähren Entsprechungen zwischen den Standards sind:

Abbildung 2:syslog-, Android- und Java-Protokollierungsebenen

Richtlinien für die Protokollebene

Für jeden Protokollstandard gibt es bereits vorhandene Richtlinien. Die ausgewählte Protokollebene entspricht dem entsprechenden Standard, z. B. dem syslog-Standard für die Kernelentwicklung.

Die Reihenfolge der Logebenen, von niedrigster zu höchster, ist in den drei Abbildungen unten dargestellt:

Abbildung 3:android.util.Log

Abbildung 4:java.util.Logging.Level.

Abbildung 5:RFC 5424 – Abschnitt 6.2.1.

App-Logging

Die selektive Protokollierung erfolgt mit der Klasse TAG nach android.util.Log mit Log#isLoggable, wie unten dargestellt:

if (Log.isLoggable("FOO_TAG", Log.VERBOSE)) {
 Log.v("FOO_TAG", "Message for logging.");
}

Logs können zur Laufzeit so angepasst werden, dass eine bestimmte Logging-Ebene bereitgestellt wird, wie unten dargestellt:

adb shell setprop log.tag.FOO_TAG VERBOSE

log.tag.*-Properties werden beim Neustart zurückgesetzt. Es gibt auch persistente Varianten, die auch nach einem Neustart bestehen bleiben. Siehe unten:

adb shell setprop persist.log.tag.FOO_TAG VERBOSE

Log#isLoggable-Prüfungen hinterlassen Protokollspuren im App-Code. Boolesche DEBUG-Flags umgehen Protokoll-Traces mit Compileroptimierungen, die auf false gesetzt sind, wie unten dargestellt:

private final static boolean DEBUG = false;


…
If (DEBUG) {
 Log.v("FOO_TAG", "Extra debug logging.");
}

Die Protokollierung kann bis zum R8 per APK über ProGuard-Regeln zur Kompilierungszeit entfernt werden. Im folgenden Beispiel wird alles unterhalb der INFO-Ebene für android.util.Log entfernt:

# This allows proguard to strip isLoggable() blocks containing only <=INFO log
# code from release builds.
-assumenosideeffects class android.util.Log {
  static *** i(...);
  static *** d(...);
  static *** v(...);
  static *** isLoggable(...);
}
-maximumremovedandroidloglevel 4

Dies ist nützlich, wenn mehrere App-Build-Typen verarbeitet werden (z. B. Entwicklungs- und Release-Builds), bei denen der zugrunde liegende Code gleich sein soll, die zulässigen Protokollebenen jedoch unterschiedlich sind. Für Apps (insbesondere System-Apps) muss eine explizite Richtlinie festgelegt und befolgt werden, um zu entscheiden, wie sich Buildtypen und Release-Erwartungen auf die Protokollausgabe auswirken.

Systemprotokollierung in der Android Runtime (ART)

Es gibt mehrere Klassen, die für System-Apps und ‑Dienste verfügbar sind:

Abbildung 6:Verfügbare Systemprotokollklassen und -zwecke

Obwohl android.util.Log und android.util.Slog dieselben Standards für die Logebene verwenden, ist Slog eine @hide-Klasse, die nur von der Plattform verwendet werden kann. Die EventLog-Ebenen werden den Einträgen in der Datei event.logtags in /system/etc/event-log-tags zugeordnet.

Natives Logging

Das Logging in C/C++ entspricht dem syslog-Standard. Dabei entspricht syslog(2) dem Linux-Kernel syslog, der den printk-Puffer steuert, und syslog(3) dem allgemeinen Systemlogger. Android verwendet die Bibliothek liblog für allgemeine Systemprotokolle.

liblog bietet Wrapper für die Unter-Bloggruppen mit der folgenden Makroform:

RLOGD entspricht beispielsweise [Radio log buffer ID] LOG [Debug Level]. Die wichtigsten liblog-Wrapper sind:

Abbildung 7:liblog-Wrapper

Android bietet höhere Schnittstellen für die Protokollierung, die gegenüber der direkten Verwendung von liblog bevorzugt werden, wie unten dargestellt:

Abbildung 8:Logbibliotheken höherer Ebene

Multistack-Schätzungen

Aufgrund von Unterschieden in der Detaillierung und der Ebenenintention gibt es keine eindeutige oder genaue Übereinstimmung zwischen den verschiedenen Protokollierungsstandards. Die Ebenen java.util.logging.Level und android.util.Log für Fehlerprotokolle stimmen beispielsweise nicht genau überein:

Abbildung 9:Fehlerebene im standardmäßigen Java-Logging im Vergleich zum Android-Logging

In solchen Fällen müssen Sie anhand des jeweiligen Standards ermitteln, welche Stufe angewendet werden soll.

Bei der Systementwicklung mit mehreren Komponenten auf Stackebene können Sie anhand von Abbildung 1 ermitteln, welcher Standard pro Komponente verwendet werden soll. Eine ungefähre Anleitung zu Nachrichtenebenen findest du in Abbildung 2.

Sicherheit und Datenschutz

Personenidentifizierbare Informationen dürfen nicht protokolliert werden. Dazu gehören unter anderem folgende Details:

• E‑Mail-Adressen
• Telefonnummern
• Namen

Bestimmte Details gelten auch dann als vertraulich, wenn sie nicht explizit personenidentifizierbar sind.

Informationen zur Zeitzone gelten beispielsweise nicht als personenidentifizierbar, geben aber einen Hinweis auf den ungefähren Standort eines Nutzers.

Die Protokollierungsrichtlinien und zulässigen Details müssen vor der Veröffentlichung im Rahmen der Sicherheits- und Datenschutzüberprüfung behandelt werden.

Geräteprotokolle

Der Zugriff auf alle Geräteprotokolle, einschließlich der Verwendung von android.permission.READ_LOGS, ist eingeschränkt:

• Wenn eine App im Hintergrund Zugriff auf alle Geräteprotokolle anfordert, wird die Anfrage automatisch abgelehnt, es sei denn, die App erfüllt folgende Voraussetzungen:
• Die System-UID wird freigegeben.
• Es wird ein nativer Systemprozess verwendet (UID < APP_UID).
• Verwendet DropBoxManager.
• Es wird nur auf den Ereignisprotokoll-Puffer zugegriffen.
• Verwendet die EventLog API.
• Es werden instrumentierte Tests verwendet.
• Wenn eine App im Vordergrund mit READ_LOGS Zugriff auf Geräteprotokolle anfordert, wird der Nutzer vom System aufgefordert, die Zugriffsanfrage zu genehmigen oder abzulehnen.