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