Informationen zum Logging

Dieser Artikel behandelt den Prozess der Protokollierung, einschließlich Protokollstandards, Levelrichtlinien, Klassen, Zwecken und Multistack-Approximationen.

Log standards

Die Protokollierung in Android ist aufgrund der Kombination von Standards, die in logcat zusammengefasst. Die wichtigsten Standards werden im Folgenden beschrieben:

Source Beispiele Hinweise auf Stackebene
RFC 5424 (syslog Standard) Linux-Kernel, viele Unix-Anwendungen Kernel, System-Daemons
android.util.Log Android-Framework und App-Logging Android-Framework und -System-App
java.util.logging.Level Allgemeines Logging in Java systemeigene App

Abbildung 1:Standards auf Logebene.

Obwohl jeder dieser Standards einen ähnlichen Aufbau hat, unterscheiden sie sich in Detaillierungsgrad. Ungefähre Entsprechungen für die Standards:

RFC 5424-Level Schweregrad gemäß RFC 5424 RFC 5424-Beschreibung android.util.Log java.util.logging.Level.
0 Notfall System ist nicht nutzbar Log.e / Log.wtf SEVERE
1 Warnmeldung Maßnahmen müssen sofort ergriffen 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 Hinweis Normal, aber signifikant Log.w WARNING
6 Info Messaging Log.i INFO
7 Fehler beheben Meldungen auf Debug-Ebene Log.d CONFIG, FINE
- - Ausführliche Botschaft Log.v FINER/FINEST

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

Richtlinien auf Logebene

Für jeden Logstandard gibt es bestehende Richtlinien. Das ausgewählte Log entspricht dem jeweiligen Standard, z. B. durch die Verwendung von syslog. für die Kernel-Entwicklung.

Die Reihenfolge auf Protokollebene, vom kleinsten bis zum größten, 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 Logs werden kompiliert, aber zur Laufzeit entfernt.
VERBOSE Diese Logs werden nie in eine Anwendung kompiliert, außer während Entwicklung.

Abbildung 3:android.util.Log

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

Abbildung 4:java.util.Logging.Level.

0 Notfall System ist nicht nutzbar
1 Warnmeldung Maßnahmen müssen sofort ergriffen werden
2 Kritisch Kritische Bedingungen
3 Fehler Fehlerbedingungen
4 Warnung Warnbedingungen
5 Hinweis Normaler, aber signifikanter Zustand
6 Information Mitteilungen zur Information
7 Fehler beheben Meldungen auf Debug-Ebene

Abbildung 5: RFC 5424 – Abschnitt 6.2.1

Anwendungs-Logging

Das selektive Logging wird mit TAG von der Klasse android.util.Log unter Verwendung von Log#isLoggable durchgeführt, wie unten dargestellt:

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

Logs können während der Laufzeit optimiert werden, um eine ausgewählte Protokollierungsebene bereitzustellen, wie gezeigt. unten:

adb shell setprop log.tag.FOO_TAG VERBOSE

log.tag.* Eigenschaften werden beim Neustart zurückgesetzt. Es gibt persistenten Varianten, die auch bei Neustarts erhalten bleiben. Siehe unten:

adb shell setprop persist.log.tag.FOO_TAG VERBOSE

Log#isLoggable-Prüfungen hinterlassen Log-Traces im App-Code. Boolescher Wert DEBUG-Flags umgehen Log-Traces mithilfe von Compiler-Optimierungen, die auf false, wie unten gezeigt:

private final static boolean DEBUG = false;

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

Logging kann über ProGuard-Regelsätze von R8 pro APK entfernt werden: der Kompilierungszeit. Im folgenden Beispiel wird alles unter der Ebene „INFO“ entfernt Logging 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 Verarbeitung mehrerer App-Build-Typen (für (z. B. Entwicklungs-Builds oder Release-Builds), bei denen der zugrunde liegende Code werden vermutlich identisch sein, die zulässigen Logebenen unterscheiden sich jedoch. Eine explizite muss für Apps konfiguriert und eingehalten werden, insbesondere für Apps), um zu entscheiden, wie sich Build-Typen und Release-Erwartungen auf das Log auswirken .

Systemprotokollierung in Android Runtime (ART)

Es gibt mehrere verfügbare Klassen, die für systemeigene Apps und Dienste:

Kurs Zweck
android.telephony.Rlog Radioprotokollierung
android.util.Log Allgemeines Anwendungs-Logging
android.util.EventLog Protokollierung von Diagnoseereignissen für Systemintegratoren
android.util.Slog Logging des Plattform-Frameworks

Abbildung 6:Verfügbare Systemlogklassen und -zwecke.

Obwohl android.util.Log und android.util.Slog dieselbe Logebene verwenden Standard ist Slog eine @hide-Klasse, die nur von der Plattform verwendet werden kann. Das EventLog Ebenen sind den Einträgen in event.logtags zugeordnet. Datei in /system/etc/event-log-tags.

Natives Logging

Die Protokollierung in C/C++ folgt dem syslog-Standard, wobei syslog(2) den den Linux-Kernel syslog, der den Zwischenspeicher printk steuert, und syslog(3) die dem allgemeinen Systemprotokoll entsprechen. Android verwendet die liblog für allgemeines System-Logging.

liblog stellt Wrapper für die Unterloggruppen mit dem folgenden Makro bereit Formular:

[Sublog Buffer ID] LOG [Log Level ID]

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

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

Abbildung 7:liblog-Wrapper.

Android hat übergeordnete Schnittstellen für die Protokollierung, die gegenüber direkten Servern bevorzugt werden. Nutzung von liblog, wie unten zu sehen:

Mediathek Nutzung
async_safe Bibliothek nur für das Logging in Umgebungen, in denen asynchrone Signale unterstützt werden
libbase Logging-Bibliothek, die eine C++-Stream-Schnittstelle für das Logging bietet, ähnlich wie Logging im Google-Stil (glog). libbase kann in beiden externen Projekten verwendet werden und ist in Apps mit libbase_ndk verfügbar.

Abbildung 8:Höhere Logbibliotheken.

Multistack-Schätzungen

Aufgrund von Unterschieden beim Detaillierungsgrad und der Absicht, unterschiedlichen Protokollierungsstandards genau übereinstimmen. Beispiel: Der Parameter java.util.logging.Level- und android.util.Log-Ebenen für Fehlerlogs sind keine 1:1-Übereinstimmung:

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

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

Legen Sie in solchen Fällen anhand des jeweiligen Standards fest, anwenden.

Bei der Systementwicklung mit mehreren Komponenten auf Stack-Ebene Abbildung 1 zeigt, welcher Standard pro Komponente verwendet werden soll. Für eine ungefähre Anleitung zum Stufen-Messaging, siehe Abbildung 2.

Sicherheit und Datenschutz

Protokolliere keine personenidentifizierbaren Informationen. Dieses enthält Details wie:

  • E-Mail-Adressen
  • Telefonnummern
  • Namen

Bestimmte Details gelten auch dann als sensibel, wenn sie die nicht personenbezogene Daten enthalten.

Auch wenn Zeitzoneninformationen nicht als personenbezogene Daten gelten, sondern gibt den ungefähren Standort eines Nutzers an.

Logrichtlinien und zulässige Details müssen im Rahmen der Sicherheits- und vor der Veröffentlichung prüfen.

Geräteprotokolle

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 werden, es sei denn, die App:
    • Teilt die System-UID.
    • Verwendet einen nativen Systemprozess (UID < APP_UID).
    • Verwendet DropBoxManager.
    • Greift nur auf den Zwischenspeicher des Ereignisprotokolls zu.
    • Verwendet die EventLog API.
    • Verwendet instrumentierte Tests.
  • Wenn eine App im Vordergrund mit READ_LOGS Zugriff auf Geräteprotokolle anfordert, wird der wird der Nutzer aufgefordert, die Zugriffsanfrage zu genehmigen oder abzulehnen.