Protokollierung verstehen

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

Protokollstandards

Die Anmeldung in Android ist aufgrund der Mischung der verwendeten Standards, die in logcat kombiniert sind, komplex. Nachfolgend sind die wichtigsten verwendeten Standards 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 Nicht-Systemanwendung

Abbildung 1: Standards auf Protokollebene.

Obwohl jeder dieser Standards einen ähnlichen Ebenenaufbau aufweist, unterscheiden sie sich in der Granularität. Ungefähre Äquivalente in 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 Bedingungen Log.e / Log.wtf SEVERE
3 Fehler Fehlerbedingungen Log.e SEVERE
4 Warnung Warnbedingungen Log.w WARNING
5 Beachten 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 zur Protokollebene

Für jeden Protokollstandard gibt es Richtlinien. Die gewählte Protokollebene richtet sich nach dem entsprechenden verwendeten Standard, z. B. nach der Verwendung des syslog Standards für die Kernel-Entwicklung.

Die Reihenfolge der Protokollebenen, von der niedrigsten zur höchsten, wird 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 Ablaufverfolgungsmeldung an
FINEST Zeigt eine sehr detaillierte Ablaufverfolgungsmeldung an
INFO Nachrichtenebene für Informationsnachrichten
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 Bedingungen
3 Fehler Fehlerbedingungen
4 Warnung Warnbedingungen
5 Beachten Normaler, aber bedeutsamer Zustand
6 Informativ Informationsnachrichten
7 Debuggen Meldungen auf Debug-Ebene

Abbildung 5: RFC 5424 – Abschnitt 6.2.1 .

Anwendungsprotokollierung

Die selektive Protokollierung wird mit TAG von der Klasse android.util.Log unter Verwendung von Log#isLoggable durchgeführt, 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 Protokollspuren 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 Kompilierungszeit entfernt werden. Das folgende Beispiel entfernt alles unterhalb der Protokollierung 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, die zulässigen Protokollebenen jedoch 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)

Für Systemanwendungen und -dienste stehen mehrere Klassen zur Verfügung:

Klasse Zweck
android.telephony.Rlog Funkprotokollierung
android.util.Log Allgemeine Anwendungsprotokollierung
android.util.EventLog Protokollierung von Diagnoseereignissen für Systemintegratoren
android.util.Slog Protokollierung des Plattform-Frameworks

Abbildung 6: Verfügbare Systemprotokollklassen und -zwecke.

Obwohl android.util.Log und android.util.Slog dieselben Protokollebenenstandards 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 Linux-Kernel- syslog 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 mithilfe der folgenden Makroform bereit:

[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 höherstufige Schnittstellen für die Protokollierung, die der direkten Verwendung liblog vorgezogen werden, wie unten dargestellt:

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

Abbildung 8: Protokollbibliotheken höherer Ebene.

Multistack-Annäherungen

Aufgrund der unterschiedlichen Granularität und Ebenenabsicht gibt es keine eindeutigen oder genauen Übereinstimmungen 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: Fehlerstufe bei der Standard-Java-Protokollierung im Vergleich zur Android-Protokollierung.

In solchen Fällen bestimmen Sie anhand der individuellen Norm, welche Stufe anzuwenden ist.

Befolgen Sie bei der Systementwicklung mit mehreren Stack-Level-Komponenten Abbildung 1, um zu bestimmen, welcher Standard pro Komponente verwendet werden soll. Eine ungefähre Anleitung zum Ebenen-Messaging 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 Daten als vertraulich, auch wenn sie nicht ausdrücklich persönlich identifizierbar sind.

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

Protokollrichtlinien und akzeptable Details müssen im Rahmen der Sicherheits- und Datenschutzprüfung vor der Veröffentlichung 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 Zugriffsanfrage zu genehmigen oder abzulehnen.