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:

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:

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:

Abbildung 3: android.util.Log

Abbildung 4: java.util.Logging.Level .

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:

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:

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

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:

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:

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.