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:

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:

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:

Abbildung 3:android.util.Log

Abbildung 4:java.util.Logging.Level.

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:

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:

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

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:

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:

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.