Informazioni sul logging

Questo articolo illustra la procedura di logging, inclusi standard di log, linee guida sul livello, classi, scopi e approssimazioni multistack.

Standard dei log

L'accesso in Android è complesso a causa del mix di standard utilizzati che combinati in logcat. Di seguito vengono descritti in dettaglio i principali standard utilizzati:

Figura 1: standard a livello di log.

Sebbene ognuno di questi standard abbia una struttura a livello simile, varia granularità. Gli standard approssimati sono i seguenti:

Figura 2: livelli di logging di syslog, Android e Java.

Linee guida per il livello di log

Esistono delle linee guida esistenti per ogni standard di log. Il log scelto segue lo standard appropriato utilizzato, ad esempio l'utilizzo dell'syslog per lo sviluppo del kernel.

Gli ordini a livello di log, dal più basso al più grande, sono mostrati nelle tre figure seguenti:

Figura 3: android.util.Log

Figura 4: java.util.Logging.Level.

Figura 5: RFC 5424 - Sezione 6.2.1.

Logging delle app

Il logging selettivo viene eseguito con TAG dalla classe android.util.Log utilizzando Log#isLoggable, come mostrato di seguito:

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

I log possono essere ottimizzati in fase di runtime per fornire un livello selezionato di logging, come mostrato sotto:

adb shell setprop log.tag.FOO_TAG VERBOSE

Le proprietà di log.tag.* vengono reimpostate al riavvio. Esistono e varianti permanenti che rimangono anche durante i riavvii. Vedi sotto:

adb shell setprop persist.log.tag.FOO_TAG VERBOSE

Log#isLoggable controlli lasciano tracce di log nel codice dell'app. Valore booleano I flag DEBUG ignorano le tracce dei log utilizzando ottimizzazioni del compilatore impostate su false, come mostrato di seguito:

private final static boolean DEBUG = false;


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

Il logging può essere rimosso per ogni APK tramite i set di regole ProGuard tramite R8 all'indirizzo durante la compilazione. L'esempio seguente rimuove tutti i dati al di sotto del livello INFO logging per 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

È utile per gestire più tipi di build dell'app (ad ad esempio build di sviluppo rispetto a build di release) in cui il codice sottostante è dovrebbe essere lo stesso, ma i livelli di log consentiti sono diversi. Un'esplicita devono essere impostati e seguiti per le app (in particolare app) per stabilire l'impatto dei tipi di build e delle aspettative di rilascio nel log come output.

Logging di sistema nel runtime Android (ART)

Sono disponibili diverse classi disponibili per il sistema app e servizi:

Figura 6: classi e scopi dei log di sistema disponibili.

Sebbene android.util.Log e android.util.Slog utilizzino lo stesso livello di log standard, Slog è una classe @hide utilizzabile solo dalla piattaforma. EventLog vengono mappati alle voci in event.logtags in /system/etc/event-log-tags.

Logging nativo

L'accesso in C/C++ segue lo standard syslog con syslog(2) corrispondente a il kernel Linux syslog che controlla il buffer printk e syslog(3) corrispondente al logger di sistema generale. Android utilizza il liblog libreria per il logging generale di sistema.

liblog fornisce i wrapper per i gruppi sublogs utilizzando la seguente macro modulo:

RLOGD, ad esempio, corrisponde a [Radio log buffer ID] LOG [Debug Level]. I wrapper liblog principali sono i seguenti:

Figura 7: wrapper liblog.

Android ha interfacce di livello superiore per il logging preferite rispetto a quelle dirette Utilizzo di liblog, come mostrato di seguito:

Figura 8: librerie di log di livello superiore.

Approssimazioni multistack

A causa delle differenze nella granularità e nell'intento del livello, non ci sono corrispondenze esatte di diversi standard di logging. Ad esempio, I livelli java.util.logging.Level e android.util.Log per i log degli errori non sono un Corrispondenza 1:1:

Figura 9: livello di errore nel logging Java standard rispetto ad Android log.

In casi come questo, utilizza il singolo standard per determinare a quale livello .

Durante lo sviluppo del sistema con più componenti a livello di stack, segui Figura 1 per determinare quale standard utilizzare per componente. Per una stima approssimativa guida ai messaggi sui livelli, come illustrato nella Figura 2.

Sicurezza e privacy

Non registrare informazioni che consentono l'identificazione personale (PII). Questo include dettagli quali:

• Indirizzi email.
• Numeri di telefono
• Nomi.

Analogamente, alcuni dettagli sono considerati sensibili, anche se non che consentono l'identificazione personale esplicitamente.

Ad esempio, anche se le informazioni sul fuso orario non sono considerate identificabili personalmente, ma dà un'indicazione della posizione approssimativa di un utente.

I criteri di log e i dettagli accettabili devono essere gestiti nell'ambito della sicurezza e e la revisione della privacy prima di rilasciarle.

Log dispositivo

Accesso a tutti i log del dispositivo, incluso l'utilizzo android.permission.READ_LOGS è limitato:

• Se un'app in background richiede l'accesso a tutti i log del dispositivo, la richiesta viene automaticamente negata a meno che l'app:
• Condivide l'UID di sistema.
• Utilizza un processo di sistema nativo (UID < APP_UID).
• Usa DropBoxManager.
• Accede solo al buffer dei log eventi.
• Utilizza l'API EventLog.
• Utilizza test strumentati.
• Se un'app in primo piano con READ_LOGS richiede l'accesso ai log del dispositivo, richiede all'utente di approvare o rifiutare la richiesta di accesso.