10 votes

Quel est le format des journaux d'Android ?

J'essaie de collecter des données sur mon téléphone en analysant les fichiers journaux de l'appareil. /dev/log . Je cherche spécifiquement /dev/log/main . J'ai toujours pensé que tout format de journal sain serait du texte brut, mais ces fichiers semblent être soit binaires, soit dans un jeu de caractères que ni moi ni mes éditeurs de texte Linux ne pouvons identifier.

Quel est le format ?

Voici quelques captures d'écran :

  • Tout d'abord, voici un extrait du journal tel qu'il est interprété par vim ( ^@ fait référence à l'octet nul ; je ne suis pas sûr des autres séquences de contrôle colorées) : vim

  • Ensuite, voici à quoi ressemble le journal dans un éditeur hexagonal : hex editor

J'utilise un Galaxy Nexus sous Jelly Bean. Les journaux ont été collectés en utilisant Root et un émulateur de terminal, car aLogcat ne semble pas utiliser Root et ne peut donc pas accéder à toutes les informations de journalisation.

6voto

Milner Points 533

Si vous voulez des informations saines, je vous recommande des commandes saines :) (sans vouloir vous offenser, je plaisante). La question devrait donc être la suivante :

Comment obtenir des informations de journal à partir d'un appareil Android ?

Et maintenant, nous sommes du bon côté. Il existe de multiples approches qui peuvent être utilisées :

  • utiliser des applications pour afficher les informations du journal (avec un code de couleur)
  • utiliser ADB (qui fait partie du SDK Android) pour extraire à distance les mêmes informations.
  • utiliser ssh à distance (ou une application de terminal locale) pour obtenir les informations directement de l'appareil.

Pour traiter pleinement ce sujet, il faut plus que cette simple réponse (si vous êtes intéressé, vous pouvez par exemple trouver des informations plus détaillées sur de nombreux sites web, ou dans le livre d'Andrew Hoog Android Forensics : Investigation, analyse et sécurité mobile pour Google Android que j'ai eu l'honneur de traduire en allemand. Il existe probablement de nombreuses autres sources.

Je vais donc vous donner quelques exemples pour vous aider à démarrer :

Utilisation des applications

L'application probablement la plus connue dans ce contexte est aLogcat disponible gratuitement sur le playstore (et le développeur acceptera volontiers votre don pour l'autre variante de la même application). Vous trouverez une capture d'écran ci-dessous 1 . L'application vous permet de filtrer les journaux, de démarrer/arrêter l'enregistrement des messages et même de stocker les extraits enregistrés sur votre carte SD - bien sûr en texte clair, comme vous l'avez demandé.

Une autre application de cette section est Collecteur de journaux qui tente simplement de récupérer l'intégralité du journal disponible et de l'envoyer via le menu de partage. 2 .

aLogCatLog Collector

Le pont de débogage Android (ADB)

Le kit de développement logiciel (SDK) Android comprend les éléments suivants adb pour diverses tâches. Il offre, entre autres, les fonctionnalités suivantes adb shell pour exécuter des commandes sur l'appareil. En utilisant cela, vous pouvez également recueillir les informations de journal souhaitées : Il suffit de préfixer les commandes ci-dessous avec adb shell .

Invite de commande sur l'appareil

En utilisant une application de terminal (par exemple Émulateur de terminal Android ou Terminal IDE ), vous pouvez accéder aux journaux directement à l'invite de commande, en local sur votre appareil. De manière un peu plus confortable, cela peut être fait en utilisant un serveur ssh (par ex. DroidSSHd ou Serveur SSH DropBear ) sur votre appareil, puis accédez-y depuis votre ordinateur. Ainsi, vous pouvez travailler sur un grand écran, tout en examinant vos journaux.

Commandes pour accéder aux informations de votre journal

Il existe un grand nombre de commandes puissantes que vous pouvez utiliser pour accéder aux informations de vos journaux à partir de la ligne de commande, et je ne donnerai que quelques exemples ici.

dmesg

El dmesg extrait le journal du noyau :

$ dmesg
<6>[82839.126586] PM: Syncing filesystems ... done.
<7>[82839.189056] PM: Preparing system for mem sleep
<4>[82839.189361] Freezing user space processes ... (elapsed 0.05 seconds) done.
<4>[82839.240661] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
<7>[82839.242279] PM: Entering mem sleep
<4>[82839.242889] Suspending console(s) (use no_console_suspend to debug)
<7>[82839.252410] vfp_pm_save_context: saving vfp state
<6>[82839.252716] PM: Resume timer in 26 secs (864747 ticks at 32768 ticks/sec.)
<6>[82842.091369] Successfully put all powerdomains to target state
<6>[82842.092468] wakeup wake lock: wifi_wake

logcat

Avec logcat vous pouvez accéder à de nombreuses informations de journalisation, mais la plupart du temps, il vous faudra utiliser Root. Il a quelques paramètres pour filtrer l'information, par exemple en sélectionnant le tampon de log à lire avec -b . Veuillez lire les informations fournies sur le page des développeurs sur logcat pour les détails. Pour vous donner deux exemples : logcat -b events affiche les événements, ou logcat -b radio des informations sur le module radio de votre appareil.

dumpsys et dumpstate

Les deux commandes dumpsys y dumpstate vous donnent des informations détaillées sur le système :

$ dumpsys
Currently running services:
    LocationProxyService
    SurfaceFlinger
    accessibility
    account
    activity
<snip>
DUMP OF SERVICE account:
Accounts: 1
    Account {name=xxxxxxx@googlemail.com, type=com.google}
<snip>
DUMP OF SERVICE alarm:

$ dumpstate
========================================================
== dumpstate: 2012-08-18 23:39:53
========================================================
Build: Gingerbread GWK74 - CyanogenMilestone2
Bootloader: 0x0000
Radio: unknown
<snip>
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 487344 kB
MemFree:   10436 kB
Buffers:   14136 kB
Cached:    145460 kB
<snip>

rapport de bogue

Et si vous êtes trop paresseux pour vous les rappeler tous, utilisez simplement la fonction bugreport qui appelle tout ce qui précède et le regroupe dans un joli, humm, rapport de bogue au développeur...

Bien sûr, vous pouvez rediriger la sortie de toutes ces commandes vers un fichier à copier sur votre ordinateur, et dans la plupart des cas vous devriez le faire -- car votre tampon d'écran serait bien trop petit pour tout gérer : bugreport > /mnt/sdcard/bugreport.txt serait un exemple pour cette partie.

5voto

Lekensteyn Points 1552

Pour les développeurs (ou autres parties intéressées) qui doivent analyser ce fichier brut, voici quelques ressources :

Le format réel du journal est détaillé à l'adresse suivante :

Une copie des parties pertinentes, légèrement annotées et réorganisées pour votre commodité :

#define LOGGER_ENTRY_MAX_LEN (5*1024)

struct log_msg {
    union {
        /* Maximum size of entry: 5121 bytes */
        unsigned char buf[LOGGER_ENTRY_MAX_LEN + 1];

        struct logger_entry_v3 entry;
        struct logger_entry_v3 entry_v3;
        struct logger_entry_v2 entry_v2;
        struct logger_entry entry_v1;
    } __attribute__((aligned(4)));
}
/*
 * The userspace structure for version 1 of the logger_entry ABI.
 * This structure is returned to userspace by the kernel logger
 * driver unless an upgrade to a newer ABI version is requested.
 */
struct logger_entry {
    uint16_t    len;    /* length of the payload */
    uint16_t    __pad;  /* no matter what, we get 2 bytes of padding */
    int32_t     pid;    /* generating process's pid */
    int32_t     tid;    /* generating process's tid */
    int32_t     sec;    /* seconds since Epoch */
    int32_t     nsec;   /* nanoseconds */
    char        msg[0]; /* the entry's payload */
} __attribute__((__packed__));

/*
 * The userspace structure for version 2 of the logger_entry ABI.
 * This structure is returned to userspace if ioctl(LOGGER_SET_VERSION)
 * is called with version==2; or used with the user space log daemon.
 */
struct logger_entry_v2 {
    uint16_t    len;    /* length of the payload */
    uint16_t    hdr_size; /* sizeof(struct logger_entry_v2) */
    int32_t     pid;    /* generating process's pid */
    int32_t     tid;    /* generating process's tid */
    int32_t     sec;    /* seconds since Epoch */
    int32_t     nsec;   /* nanoseconds */
    uint32_t    euid;   /* effective UID of logger */
    char        msg[0]; /* the entry's payload */
} __attribute__((__packed__));

struct logger_entry_v3 {
    uint16_t    len;    /* length of the payload */
    uint16_t    hdr_size; /* sizeof(struct logger_entry_v3) */
    int32_t     pid;    /* generating process's pid */
    int32_t     tid;    /* generating process's tid */
    int32_t     sec;    /* seconds since Epoch */
    int32_t     nsec;   /* nanoseconds */
    uint32_t    lid;    /* log id of the payload */
    char        msg[0]; /* the entry's payload */
} __attribute__((__packed__));

Vous pouvez distinguer les différentes versions en regardant le troisième et le quatrième octet. Le format dépend apparemment aussi de l'endive de votre plate-forme. Pour les messages v1, __pad est égal à 0 . les messages v2 (et v3) utilisent 24 ( 0x18 ).

Pour main , radio y system journaux msg est interprété comme suit ( source ):

  • priorité : 1 octet
  • tag : 0 ou plusieurs octets
  • littéral \0 comme séparateur
  • message : 0 octet ou plus
  • littéral \0 comme terminateur

Si ce message est tronqué, le message de fin de ligne \0 peut manquer.

Pour events journal cependant, msg contiennent les données binaires suivantes :

  • Tag : Clé entière de 4 octets provenant du fichier "/system/etc/event-log-tags".
  • Message : arbre sérialisé commençant par le nœud Root. Chaque nœud de l'arbre commence par une valeur de 1 octet de l'énumération AndroidEventLogType :
    • EVENT_TYPE_INT - la valeur du nœud est un entier de 4 octets
    • EVENT_TYPE_LONG - la valeur du nœud est un entier de 8 octets
    • EVENT_TYPE_STRING - la valeur du nœud est un entier de 4 octets length suivi par le length octets contenant une chaîne de caractères codée en UTF8
    • EVENT_TYPE_LIST - la valeur du nœud est un octet unique. length suivi par le length des nœuds d'arbre, chacun ayant sa propre AndroidEventLogType .

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X