Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Lire les rapports de bogue

Les bogues sont une réalité dans tout type de développement et les rapports de bogues sont essentiels pour identifier et résoudre les problèmes. Toutes les versions d'Android prennent en charge la capture de rapports de bogues avec Android Debug Bridge (adb) ; Les versions Android 4.2 et supérieures prennent en charge une option développeur pour la prise de rapports de bogues et le partage par e-mail, Drive, etc.

Les rapports de bogues Android contiennent des données dumpsys , dumpstate et logcat au format texte (.txt), vous permettant de rechercher facilement un contenu spécifique. Les sections suivantes détaillent les composants du rapport de bogue, décrivent les problèmes courants et donnent des conseils utiles et des commandes grep pour trouver les journaux associés à ces bogues. La plupart des sections incluent également des exemples pour la commande grep et la sortie et / ou la sortie dumpsys .

Logcat

Le journal logcat est un vidage basé sur une chaîne de toutes les informations logcat . La partie système est réservée au framework et a une histoire plus longue que main qui contient tout le reste. Chaque ligne commence par l' timestamp PID TID log-level .

Affichage du journal des événements

Ce journal contient des représentations sous forme de chaîne de messages de journal au format binaire. Il est moins bruyant que le journal logcat mais aussi un peu plus difficile à lire. Lors de l'affichage des journaux d'événements, vous pouvez rechercher dans cette section un ID de processus (PID) spécifique pour voir ce qu'un processus a fait. Le format de base est le suivant: timestamp PID TID log-level log-tag tag-values .

Les niveaux de journal incluent les éléments suivants:

  • V: verbeux
  • D: débogage
  • I: information
  • W: avertissement
  • E: erreur

Pour d'autres balises de journal des événements utiles, reportez-vous à /services/core/java/com/android/server/EventLogTags.logtags .

ANR et impasses

Les rapports de bogue peuvent vous aider à identifier ce qui cause les erreurs ANR (Application Not Responding) et les événements de blocage.

Identifier les applications qui ne répondent pas

Lorsqu'une application ne répond pas dans un certain temps, généralement en raison d'un thread principal bloqué ou occupé, le système arrête le processus et vide la pile dans /data/anr . Pour découvrir le coupable derrière un ANR, grep pour am_anr dans le journal des événements binaires.

Vous pouvez également grep pour ANR in le journal logcat , qui contient plus d'informations sur ce qui utilisait le CPU au moment de l'ANR.

Recherche de traces de pile

Vous pouvez souvent trouver des traces de pile qui correspondent à un ANR. Assurez-vous que l'horodatage et le PID sur les traces de VM correspondent à l'ANR que vous étudiez, puis vérifiez le thread principal du processus. Gardez à l'esprit:

  • Le thread principal vous indique uniquement ce que le thread faisait au moment de l'ANR, qui peut ou non correspondre à la véritable cause de l'ANR. (La pile dans le rapport de bogue peut être innocente; quelque chose d'autre peut avoir été bloqué pendant longtemps - mais pas assez longtemps pour l'ANR - avant de se décoller.)
  • Plusieurs ensembles de traces de pile ( VM TRACES JUST NOW et VM TRACES AT LAST ANR ) peuvent exister. Assurez-vous que vous affichez la bonne section.

Trouver des blocages

Les blocages apparaissent souvent d'abord comme des ANR parce que les threads sont bloqués. Si le blocage atteint le serveur système, le chien de garde finira par le tuer, conduisant à une entrée dans le journal semblable à: WATCHDOG KILLING SYSTEM PROCESS . Du point de vue de l'utilisateur, l'appareil redémarre, bien qu'il s'agisse techniquement d'un redémarrage à l'exécution plutôt que d'un véritable redémarrage.

  • Lors d'un redémarrage à l' exécution , le serveur système meurt et est redémarré; l'utilisateur voit l'appareil revenir à l'animation de démarrage.
  • Lors d'un redémarrage , le noyau s'est écrasé; l'utilisateur voit l'appareil revenir au logo de démarrage de Google.

Pour trouver des blocages, vérifiez les sections de traces de VM pour un modèle de thread A en attente sur quelque chose détenu par le thread B, qui à son tour attend quelque chose détenu par le thread A.

Activités

Une activité est un composant d'application qui fournit un écran avec lequel les utilisateurs interagissent pour faire quelque chose comme composer un numéro, prendre une photo, envoyer un e-mail, etc. Du point de vue du rapport de bogue, une activité est une chose unique et ciblée qu'un utilisateur peut faire , ce qui rend très important la localisation de l'activité ciblée lors d'un accident. Les activités (via ActivityManager) exécutent des processus, de sorte que la localisation de tous les arrêts et démarrages de processus pour une activité donnée peut également faciliter le dépannage.

Affichage des activités ciblées

Pour afficher l'historique des activités ciblées, recherchez am_focused_activity .

Le processus de visualisation démarre

Pour afficher un historique des démarrages de processus, recherchez Start proc .

L'appareil se débat-il?

Pour déterminer si le périphérique se débat , recherchez une augmentation anormale de l'activité autour de am_proc_died et am_proc_start dans un court laps de temps.

Mémoire

Étant donné que les appareils Android ont souvent une mémoire physique limitée, la gestion de la mémoire vive (RAM) est essentielle. Les rapports de bogue contiennent plusieurs indicateurs de mémoire insuffisante ainsi qu'un état de vidage qui fournit un instantané de la mémoire.

Identification de la mémoire insuffisante

Une mémoire insuffisante peut provoquer des pannes du système car il tue certains processus pour libérer de la mémoire mais continue de démarrer d'autres processus. Pour afficher les preuves corroborant une mémoire insuffisante, recherchez les concentrations d'entrées am_proc_died et am_proc_start dans le journal des événements binaires.

Une mémoire insuffisante peut également ralentir le changement de tâche et contrecarrer les tentatives de retour (car la tâche à laquelle l'utilisateur essayait de revenir a été tuée). Si le lanceur a été tué, il redémarre lorsque l'utilisateur touche le bouton d'accueil et les journaux indiquent que le lanceur recharge son contenu.

Affichage des indicateurs historiques

L'entrée am_low_memory dans le journal des événements binaires indique que le dernier processus mis en cache est mort. Après cela, le système commence à tuer les services.

Affichage des indicateurs de battage

D'autres indicateurs de battement du système (pagination, récupération directe, etc.) incluent les cycles de consommation de kswapd , kworker et mmcqd . (Gardez à l'esprit que le rapport de bogue collecté peut influencer les indicateurs de battage.)

Les journaux ANR peuvent fournir un instantané de mémoire similaire.

Obtenir un instantané de la mémoire

L'instantané de mémoire est un état de vidage qui répertorie les processus Java et natifs en cours d'exécution (pour plus de détails, reportez-vous à Affichage des allocations de mémoire globales ). Gardez à l'esprit que l'instantané ne donne que l'état à un moment précis dans le temps; le système était peut-être en meilleure forme (ou pire) avant l'instantané.

Diffusions

Les applications génèrent des diffusions pour envoyer des événements dans l'application actuelle ou vers une autre application. Les récepteurs de diffusion s'abonnent à des messages spécifiques (via des filtres), ce qui leur permet à la fois d'écouter et de répondre à une diffusion. Les rapports de bogue contiennent des informations sur les diffusions envoyées et les diffusions non envoyées, ainsi qu'une liste de tous les récepteurs écoutant une diffusion spécifique.

Affichage des émissions historiques

Les émissions historiques sont celles qui ont déjà été envoyées, classées dans l'ordre chronologique inverse.

La section récapitulative est un aperçu des 300 dernières diffusions au premier plan et des 300 dernières diffusions en arrière-plan.

La section détaillée contient des informations complètes sur les 50 dernières diffusions au premier plan et les 50 dernières diffusions en arrière-plan, ainsi que les récepteurs de chaque diffusion. Récepteurs qui ont:

  • BroadcastFilter entrées BroadcastFilter sont enregistrées lors de l'exécution et sont envoyées uniquement aux processus déjà en cours d'exécution.
  • ResolveInfo entrées ResolveInfo sont enregistrées via des entrées de manifeste. ActivityManager démarre le processus pour chaque ResolveInfo s'il n'est pas déjà en cours d'exécution.

Affichage des diffusions actives

Les diffusions actives sont celles qui n'ont pas encore été envoyées. Un grand nombre dans la file d'attente signifie que le système ne peut pas distribuer les diffusions assez rapidement pour suivre le rythme.

Affichage des auditeurs de diffusion

Pour afficher la liste des récepteurs écoutant une diffusion, consultez la table de dumpsys activity broadcasts des récepteurs dans les dumpsys activity broadcasts . L'exemple suivant affiche tous les récepteurs écoutant USER_PRESENT .

Surveiller les conflits

La journalisation des conflits de surveillance peut parfois indiquer un conflit de moniteur réel, mais indique le plus souvent que le système est tellement chargé que tout s'est ralenti. Vous pouvez voir de longs événements de surveillance enregistrés par ART dans le système ou le journal des événements.

Dans le journal système:

10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

Dans le journal des événements:

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

Compilation d'arrière-plan

La compilation peut être coûteuse et charger l'appareil.

La compilation peut se produire en arrière-plan lors du téléchargement des mises à jour de Google Play Store. Dans ce cas, les messages de l'application Google Play Store ( finsky ) et installd apparaissent avant les messages dex2oat .

La compilation peut également se produire en arrière-plan lorsqu'une application charge un fichier dex qui n'a pas encore été compilé. Dans ce cas, vous ne verrez pas la finsky ou installd .

Récit

L'établissement du récit d'un problème (comment il a commencé, ce qui s'est passé, comment le système a réagi) nécessite une chronologie solide des événements. Vous pouvez utiliser les informations du rapport de bogue pour synchroniser les chronologies sur plusieurs journaux et déterminer l'horodatage exact du rapport de bogue.

Synchroniser les chronologies

Un rapport de bogue reflète plusieurs chronologies parallèles: journal système, journal des événements, journal du noyau, et plusieurs chronologies spécialisées pour les diffusions, statistiques de batterie, etc. Malheureusement, les chronologies sont souvent rapportées en utilisant des bases de temps différentes.

Les horodatages du système et du journal des événements sont dans le même fuseau horaire que l'utilisateur (comme la plupart des autres horodatages). Par exemple, lorsque l'utilisateur appuie sur le bouton d'accueil, le journal système signale:

10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

Pour la même action, le journal des événements rapporte:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

Les journaux du noyau ( dmesg ) utilisent une base de temps différente, marquant les éléments du journal avec les secondes écoulées depuis la fin du chargeur de démarrage. Pour enregistrer cette échelle de temps sur d'autres échelles de temps, recherchez suspendre la sortie et suspendre les messages d' entrée :

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

Étant donné que les journaux du noyau peuvent ne pas inclure le temps pendant la suspension, vous devez enregistrer le journal par morceaux entre les messages d'entrée et de sortie de suspension. De plus, les journaux du noyau utilisent le fuseau horaire UTC et doivent être ajustés au fuseau horaire de l'utilisateur.

Identifier l'heure de rapport de bogue

Pour déterminer quand un rapport de bogue a été effectué, vérifiez d'abord le journal système (Logcat) pour l'état de dumpstate: begin :

10-03 17:19:54.322 19398 19398 I dumpstate: begin

Ensuite, vérifiez les horodatages du journal du noyau ( dmesg ) pour le message Starting service 'bugreport' :

<5>[207064.285315] init: Starting service 'bugreport'...

Travaillez à rebours pour corréler les deux événements, en gardant à l'esprit les mises en garde mentionnées dans la chronologie de synchronisation . Bien qu'il se passe beaucoup de choses après le lancement du rapport de bogue, la plupart des activités ne sont pas très utiles car le fait de prendre le rapport de bogue charge considérablement le système.

Puissance

Le journal des événements contient l'état de l'alimentation de l'écran, où 0 signifie que l'écran est éteint, 1 est l'écran allumé et 2 correspond au verrouillage du clavier terminé.

Les rapports de bogue contiennent également des statistiques sur les verrous de réveil, un mécanisme utilisé par les développeurs d'applications pour indiquer que leur application a besoin que l'appareil reste allumé. (Pour plus de détails sur les verrous de réveil, reportez-vous à PowerManager.WakeLock et Keep the CPU on .)

Les statistiques de durée de verrouillage de réveil agrégées ne suivent que l'heure à laquelle un verrou de réveil est réellement responsable de garder l'appareil éveillé et n'incluent pas le temps avec l'écran allumé. En outre, si plusieurs verrous de réveil sont maintenus simultanément, la durée du verrouillage de réveil est répartie sur ces verrous de réveil.

Pour plus d'aide sur la visualisation de l'état de l'alimentation, utilisez Battery Historian , un outil open source de Google pour analyser les consommateurs de batterie à l'aide de fichiers de rapport de bogue Android.

Paquets

Le package DUMP OF SERVICE contient les versions de l'application (et d'autres informations utiles).

Processus

Les rapports de bogue contiennent une énorme quantité de données pour les processus, y compris l'heure de début et de fin, la durée d'exécution, les services associés, le score oom_adj , etc. Pour plus de détails sur la façon dont Android gère les processus, reportez-vous à Processus et Threads .

Déterminer le temps d'exécution du processus

La section procstats contient des statistiques complètes sur la durée d'exécution des processus et des services associés. Pour un résumé rapide et lisible par l'homme, recherchez AGGREGATED OVER pour afficher les données des trois ou 24 dernières heures, puis recherchez Summary: pour afficher la liste des processus, combien de temps ces processus ont été exécutés selon différentes priorités et leur RAM utilisation formatée comme PSS min-moyenne-max / USS min-moyenne-max.

Pourquoi un processus est-il en cours d'exécution?

La section des dumpsys activity processes répertorie tous les processus en cours d'exécution classés par score oom_adj (Android indique l'importance du processus en attribuant au processus une valeur oom_adj , qui peut être mise à jour dynamiquement par ActivityManager). La sortie est similaire à celle d'un instantané de mémoire, mais comprend des informations supplémentaires sur ce qui provoque l'exécution du processus. Dans l'exemple ci-dessous, les entrées en gras indiquent que le processus gms.persistent s'exécute vis la priorité vis (visible) car le processus système est lié à son NetworkLocationService .

Scans

Procédez comme suit pour identifier les applications effectuant des analyses Bluetooth Low Energy (BLE) excessives:

  • Rechercher les messages du journal pour BluetoothLeScanner :
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • Recherchez le PID dans les messages du journal. Dans cet exemple, "24840" et "24851" sont PID (ID de processus) et TID (ID de thread).
  • Localisez l'application associée au PID:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    Dans cet exemple, le nom du package est com.badapp .

  • Recherchez le nom du package sur Google Play pour identifier l'application responsable: https://play.google.com/store/apps/details?id=com.badapp .

Remarque : pour les appareils exécutant Android 7.0, le système collecte des données pour les analyses BLE et associe ces activités à l'application de lancement. Pour plus de détails, consultez Analyses basse consommation (LE) et Bluetooth .