Protokollierung verstehen

Dieser Artikel behandelt den Protokollierungsprozess, einschließlich Protokollierungsstandards, Ebenenrichtlinien, Klassen, Zwecke und Multistack-Annäherungen.

Log-Standards

Die Anmeldung in Android ist aufgrund der Mischung aus verwendeten Standards, die in logcat kombiniert werden, komplex. Die wichtigsten verwendeten Standards sind im Folgenden aufgeführt:

Quelle Beispiele Anleitung auf Stapelebene
RFC 5424 ( syslog -Standard) Linux-Kernel, viele Unix-Anwendungen Kernel, Systemdämonen
android.util.Log Android-Framework + Anwendungsprotokollierung Android-Framework und Systemanwendung
java.util.logging.Level Allgemeine Protokollierung in Java systemfremde Anwendung

Abbildung 1: Standards auf Protokollebene.

Obwohl jeder dieser Standards einen ähnlichen Ebenenaufbau hat, unterscheiden sie sich in der Granularität. Ungefähre Äquivalente zwischen den Standards sind wie folgt:

RFC 5424-Ebene RFC 5424-Schweregrad RFC 5424-Beschreibung android.util.Log java.util.logging.Level
0 Notfall System ist unbrauchbar Log.e / Log.wtf SEVERE
1 Alarm Es muss sofort gehandelt werden Log.e / Log.wtf SEVERE
2 Kritisch Kritische Zustände Log.e / Log.wtf SEVERE
3 Fehler Fehlerbedingungen Log.e SEVERE
4 Warnung Warnbedingungen Log.w WARNING
5 Notiz Normal, aber bedeutsam Log.w WARNING
6 Die Info Informationsübermittlung Log.i INFO
7 Debuggen Meldungen auf Debug-Ebene Log.d CONFIG , FINE
- - Ausführliche Nachrichten Log.v FINER / FINEST

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

Richtlinien für die Protokollebene

Es gibt bestehende Richtlinien für jeden Rundholzstandard. Die gewählte Protokollebene folgt dem entsprechenden Standard, der verwendet wird, wie die Verwendung des syslog -Standards für die Kernel-Entwicklung.

Die Reihenfolgen auf Protokollebene, von der geringsten zur höchsten, sind in den drei folgenden Abbildungen dargestellt:

ERROR Diese Protokolle werden immer aufbewahrt.
WARN Diese Protokolle werden immer aufbewahrt.
INFO Diese Protokolle werden immer aufbewahrt.
DEBUG Diese Protokolle werden kompiliert, aber zur Laufzeit entfernt.
VERBOSE Diese Protokolle werden nie in eine Anwendung kompiliert, außer während der Entwicklung.

Abbildung 3: android.util.Log

CONFIG Nachrichtenebene für statische Konfigurationsnachrichten
FINE Nachrichtenebene, die Ablaufverfolgungsinformationen bereitstellt
FINER Zeigt eine ziemlich detaillierte Ablaufverfolgungsnachricht an
FINEST Zeigt eine sehr detaillierte Ablaufverfolgungsnachricht an
INFO Meldungsebene für Informationsmeldungen
SEVERE Meldungsebene, die auf einen schwerwiegenden Fehler hinweist
WARNING Nachrichtenebene, die auf ein potenzielles Problem hinweist

Abbildung 4: java.util.Logging.Level .

0 Notfall System ist unbrauchbar
1 Alarm Es muss sofort gehandelt werden
2 Kritisch Kritische Zustände
3 Fehler Fehlerbedingungen
4 Warnung Warnbedingungen
5 Notiz Normaler aber signifikanter Zustand
6 Informativ Informative Nachrichten
7 Debuggen Meldungen auf Debug-Ebene

Abbildung 5: RFC 5424 – Abschnitt 6.2.1 .

Anwendungsprotokollierung

Die selektive Protokollierung wird mit der Klasse TAG by android.util.Log unter Verwendung von Log#isLoggable , wie unten gezeigt:

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

Protokolle können zur Laufzeit optimiert werden, um eine ausgewählte Protokollierungsebene bereitzustellen, wie unten gezeigt:

adb shell setprop log.tag.FOO_TAG VERBOSE

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

adb shell setprop persist.log.tag.FOO_TAG VERBOSE

Log#isLoggable Prüfungen hinterlassen Protokollspuren im Anwendungscode. Boolesche DEBUG -Flags umgehen Protokollablaufverfolgungen mithilfe von Compiler-Optimierungen, die auf false gesetzt sind, wie unten gezeigt:

private final static boolean DEBUG = false;

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

Die Protokollierung kann auf APK-Basis über ProGuard-Regelsätze von R8 zur Kompilierzeit entfernt werden. Das folgende Beispiel entfernt alles Protokoll unterhalb der INFO -Ebene für android.util.Log :

# 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 für die Handhabung mehrerer Anwendungs-Build-Typen (z. B. Entwicklungs-Builds vs. Release-Builds), bei denen erwartet wird, dass der zugrunde liegende Code derselbe ist, aber die zulässigen Protokollebenen unterschiedlich sind. Für Anwendungen (insbesondere Systemanwendungen) muss eine explizite Richtlinie festgelegt und befolgt werden, um zu entscheiden, wie sich Build-Typen und Release-Erwartungen auf die Protokollausgabe auswirken.

Systemprotokollierung in der Android Runtime (ART)

Es gibt mehrere verfügbare Klassen, die für Systemanwendungen und -dienste verfügbar sind:

Klasse Zweck
android.telephony.Rlog Funkprotokollierung
android.util.Log Allgemeine Anwendungsprotokollierung
android.util.EventLog Systemintegrator-Diagnoseereignisprotokollierung
android.util.Slog Plattform-Framework-Protokollierung

Abbildung 6: Verfügbare Systemprotokollklassen und -zwecke.

Obwohl android.util.Log und android.util.Slog dieselben Standards für die Protokollierung 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.

Native Protokollierung

Die Protokollierung in C/C++ folgt dem syslog -Standard, wobei syslog (2) dem syslog des Linux-Kernels entspricht, das den printk Puffer steuert, und syslog (3) dem allgemeinen System-Logger entspricht. Android verwendet die liblog Bibliothek für die allgemeine Systemprotokollierung.

liblog stellt Wrapper für die Sublogs-Gruppen bereit, die das folgende Makroformular verwenden:

[Sublog Buffer ID] LOG [Log Level ID]

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

Wrapper-Klasse Beispielfunktionen
log_main.h ALOGV , ALOGW
log_radio.h RLOGD , RLOGE
log_system.h SLOGI , SLOGW

Abbildung 7: liblog Wrapper.

Android verfügt über Schnittstellen auf höherer Ebene für die Protokollierung, die gegenüber der direkten Verwendung von liblog bevorzugt werden, wie unten zu sehen ist:

Bibliothek Verwendung
async_safe Bibliothek nur zum Protokollieren aus asynchronsignalsicheren Umgebungen
libbase Protokollierungsbibliothek, die eine C++-Stream-Schnittstelle für die Protokollierung bereitstellt, ähnlich der Protokollierung im Google-Stil (glog). libbase in beiden externen Projekten verwendet werden und ist in Anwendungen verfügbar, die libbase_ndk verwenden.

Abbildung 8: Log-Bibliotheken auf höherer Ebene.

Multistack-Annäherungen

Aufgrund von Unterschieden in Granularität und Ebenenabsicht gibt es keine eindeutigen oder exakten Zuordnungen verschiedener Protokollierungsstandards. Beispielsweise stimmen die Ebenen java.util.logging.Level und android.util.Log für Fehlerprotokolle nicht 1:1 überein:

java.util.Logging.Level android.util.Log
SCHWER Log.wtf
SCHWER Log.e

Abbildung 9: Fehlerebene beim Standard-Java-Logging im Vergleich zum Android-Logging.

Verwenden Sie in solchen Fällen den individuellen Standard, um zu bestimmen, welches Niveau anzuwenden ist.

Befolgen Sie während der Systementwicklung mit mehreren Stack-Level-Komponenten Abbildung 1, um zu bestimmen, welcher Standard pro Komponente verwendet werden soll. Eine ungefähre Anleitung zum Messaging auf Ebenen finden Sie in Abbildung 2.

Sicherheit und Privatsphäre

Protokollieren Sie keine personenbezogenen Daten (PII). Dazu gehören Details wie:

  • E-mailadressen
  • Telefonnummern
  • Namen

Ebenso gelten bestimmte Details als sensibel, auch wenn sie nicht ausdrücklich persönlich identifizierbar sind.

Obwohl Zeitzoneninformationen beispielsweise nicht als persönlich identifizierbar gelten, geben sie doch einen Hinweis auf den ungefähren Standort eines Benutzers.

Protokollrichtlinien und akzeptable 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:
    • teilt die System-UID.
    • verwendet einen nativen Systemprozess ( UID < APP_UID ).
    • verwendet DropBoxManager .
    • greift nur auf den Ereignisprotokollpuffer zu.
    • verwendet die EventLog API.
    • verwendet instrumentierte Tests.
  • Wenn eine App im Vordergrund mit READ_LOGS Zugriff auf Geräteprotokolle anfordert, fordert das System den Benutzer auf, die Zugriffsanforderung zu genehmigen oder abzulehnen.