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; |
---|
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.