Lire les rapports de bugs

Les bugs sont une réalité dans tout type de développement, et les rapports de bugs sont essentielles à l'identification et à la résolution des problèmes. Compatibilité avec toutes les versions d'Android la création de rapports de bugs avec Android Debug Bridge (adb) Android 4.2 et versions ultérieures sont compatibles avec Développeur Option permettant de créer des rapports de bugs et de les partager par e-mail, Drive, etc.

Les rapports de bug Android contiennent dumpsys, dumpstate et Données logcat au format texte (.txt), pour faciliter les recherches pour des contenus spécifiques. Les sections suivantes détaillent les composants du rapport de bug, Décrire les problèmes courants, et donner des conseils utiles et des commandes grep pour trouver les journaux associés à ces bogues. La plupart des sections comprennent é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 tous les logcat. des informations. La partie system est réservée au framework a un historique plus long que main, qui contient tout le reste. Chaque ligne commence généralement par timestamp UID PID TID log-level, bien que UID ne figure pas dans la liste dans les anciennes versions d'Android.

Consulter le 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. Lorsque vous consultez les journaux d'événements, vous pouvez rechercher l'ID de processus spécifique dans cette section (PID) pour voir ce que fait un processus. Le format de base est le suivant: timestamp PID TID log-level log-tag tag-values

Les niveaux de journalisation sont les suivants:

  • V: détaillée
  • D: déboguer
  • I: d’informations
  • W: avertissement
  • E: erreur

 

Pour connaître d'autres balises de journal des événements utiles, consultez /services/core/java/com/android/server/EventLogTags.logtags.

ANR et interblocages

Les rapports de bugs peuvent vous aider à identifier la cause du problème Application Erreurs ANR (Pas de réponse) et événements d'interblocage.

Identifier les applications qui ne répondent pas

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

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

Rechercher des traces de la pile

Vous pouvez souvent trouver des traces de pile correspondant à une erreur ANR. Assurez-vous que le paramètre le code temporel et le PID des traces de la VM correspondent à l'ANR que vous examinez, puis vérifier le thread principal du processus. À noter :

  • Le thread principal vous indique uniquement ce qu'il était en train de faire au moment de la ANR, qui peut correspondre ou non à la cause réelle de l'ANR. (L'empilement dans le rapport de bug peut être innocent ; qu'un autre élément est peut-être bloqué depuis longtemps mais pas assez longtemps pour provoquer une erreur ANR, avant de ne plus être bloqué.)
  • Plusieurs ensembles de traces de la pile (VM TRACES JUST NOW et VM TRACES AT LAST ANR). Assurez-vous de consulter la la bonne section.

Identifier les interblocages

Les interblocages apparaissent souvent sous forme d'ANR, car les threads se bloquent. Si l'interblocage touche le serveur système, le watchdog le tuera, ce qui conduit à une entrée dans le journal semblable à ceci: 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 de l'exécution un vrai redémarrage.

  • Lors d'un redémarrage d'environnement d'exécution, le serveur système se ferme et est redémarrée, l'utilisateur voit l'appareil revenir à l'animation de démarrage.
  • Lors d'un redémarrage, le noyau a planté. l'utilisateur voit l'appareil retourne au logo de démarrage Google.

Pour détecter les interblocages, recherchez dans les sections des traces de la VM un schéma de thread A. dans l'attente d'un élément détenu par le thread B, qui à son tour attend quelque chose détenu par le fil A.

Activités

Une activité est un composant d'application qui fournit un écran avec lequel les utilisateurs interagissent pour faire l'action consistant, par exemple, à composer un numéro, à prendre une photo, à envoyer un e-mail, etc. À partir d'un bug du point de vue des rapports, activité est une chose unique et ciblée qu’un utilisateur peut faire, ce qui facilite la localisation de l’activité que était très important lors d'un accident. Activités (via ActivityManager) exécuter des processus. Ainsi, la localisation de tous les processus s’arrête et démarre pour une activité donnée peut facilitent également le dépannage.

Afficher les activités sélectionnées

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

Début du processus d'affichage

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

Déterminer si l'appareil est en mode thrashing

Pour déterminer si l'appareil est thrashing, recherchez une augmentation anormale de l'activité autour de am_proc_died et am_proc_start en peu de temps.

Mémoire

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

Identifier les problèmes de mémoire insuffisante

Une mémoire insuffisante peut entraîner un thrash du système, car il arrête certains processus pour libérer mémoire, mais continue à démarrer d'autres processus. Pour afficher les preuves corroborantes mémoire insuffisante, vérifiez les concentrations de am_proc_died et Entrées am_proc_start dans le journal des événements binaires.

Une mémoire insuffisante peut également ralentir le changement de tâche et entraver les tentatives de retour (car la tâche à laquelle l'utilisateur tentait de revenir a été interrompue). Si le lanceur d'applications était s'est arrêté, il redémarre lorsque l'utilisateur appuie sur le bouton d'accueil et que les journaux indiquent actualiser le contenu du lanceur d'applications.

Afficher les indicateurs historiques

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

Afficher les indicateurs de thrashing

D'autres indicateurs de thrashing du système (pagination, récupération directe, etc.) incluent Consommation de kswapd, kworker et mmcqd cycles. (Gardez à l'esprit que le rapport de bug en cours de collecte peut influencer le thrashing ).

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

Obtenir un instantané de mémoire

L'instantané de la mémoire est un état de vidage qui répertorie les ressources Java et natives processus (pour plus de détails, reportez-vous Affichage Allocations de mémoire globales). Gardez à l'esprit que l'instantané ne fournit que l'état à un moment précis, le système aurait pu être meilleur (ou pire) avant l'instantané.

Diffusions

Les applications génèrent des diffusions pour envoyer des événements dans le flux ou vers une autre application. Les broadcast receivers s'abonnent à des messages (via des filtres), ce qui leur permet d'écouter une annonce et d'y répondre. Les rapports de bug contiennent des informations sur les diffusions envoyées et non envoyées, par exemple ainsi qu'un dumpsys de tous les récepteurs écoutant une diffusion spécifique.

Afficher l'historique des diffusions

Les diffusions historiques sont celles qui ont déjà été envoyées, répertoriées dans ordre chronologique inverse.

La section summary est un aperçu des 300 derniers et les 300 dernières diffusions en arrière-plan.

La section detail contient des informations complètes sur le 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. Les récepteurs présentant les caractéristiques suivantes:

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

Afficher les diffusions actives

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

Afficher les écouteurs de diffusion

Pour afficher la liste des récepteurs qui écoutent une annonce, cochez la case "Récepteur". Table du résolveur dans le fichier dumpsys activity broadcasts. Les éléments suivants : exemple affiche tous les récepteurs qui écoutent USER_PRESENT.

Contrôle des conflits

La journalisation des conflits de surveillance peut parfois indiquer un conflit de surveillance réel, mais cela indique le plus souvent que le système est tellement chargé que tout a ralenti. Vous pouvez voir de longs événements de surveillance enregistrés par ART dans le journal du système ou 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 en arrière-plan

La compilation peut coûter cher et charger l'appareil.

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

La compilation peut également avoir lieu en arrière-plan lors du chargement d'une application. un fichier dex qui n'a pas encore été compilé. Dans ce cas, vous ne verrez pas Journalisation finsky ou installd.

Récit

Établir le récit d'un problème (comment il a commencé, ce qui s'est passé, comment la réaction du système) nécessite une chronologie fiable des événements. Vous pouvez utiliser les informations du rapport de bug pour synchroniser les chronologies entre plusieurs journaux et déterminer l'horodatage exact du rapport de bug.

Chronologies de synchronisation

Un rapport de bug reflète plusieurs chronologies parallèles: journal système, journal des événements, le journal du noyau et de nombreuses chronologies spécialisées pour les diffusions, les statistiques de la batterie, etc. Malheureusement, les délais sont souvent calculés selon des périodes différentes.

Les codes temporels du journal des événements et du système correspondent au même fuseau horaire que celui de l'utilisateur (comme correspondent à la plupart des autres codes temporels). Par exemple, lorsque l'utilisateur appuie sur le bouton d'accueil, rapports de journal système:

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 indique:

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 et incluent des tags pour les éléments de journaux avec quelques secondes depuis la fin du bootloader. Pour enregistrer ce délai dans d'autres Timescales, recherchez les messages suspend exit et suspend entry:

<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

Comme les journaux du noyau peuvent ne pas inclure de temps en cas de suspension, vous devez enregistrer par morceaux le journal entre l'entrée de suspension et les messages de sortie. De plus, les journaux du noyau utilisent le fuseau horaire UTC et doivent être ajustés en fonction de l'utilisateur fuseau horaire.

Identifier l'heure du rapport de bug

Pour déterminer à quel moment un rapport de bug a été créé, consultez d'abord le journal système (Logcat) pour dumpstate: begin:

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

Vérifiez ensuite les horodatages du journal du noyau (dmesg) pour le message Starting service 'bugreport':

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

Travaillez en arrière pour corréler les deux événements, en gardant à l'esprit les mises en garde mentionnés dans la section Synchronisation des chronologies. Bien qu’il y ait beaucoup se produisant après le lancement du rapport de bug, la plupart de l'activité n'est pas très utile car le fait de prendre le rapport de bug charge considérablement le système.

Alimentation

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

Les rapports de bugs contiennent également des statistiques sur les wakelocks, un mécanisme utilisé par les développeurs d'applications pour indiquer que leur application doit disposer de l'appareil reste activé. Pour en savoir plus sur les wakelocks, consultez PowerManager.WakeLock et Keep le processeur.)

Les statistiques cumulées sur la durée des wakelocks ne suivent que les de temps, un wakelock est en fait responsable de maintenir l’appareil activé et n'incluez pas de temps avec l'écran allumé. De plus, si plusieurs wakelocks sont maintenus simultanément, la durée du wakelock est répartis entre ces wakelocks.

Si vous avez encore besoin d'aide pour visualiser l'état de l'alimentation, utilisez Batterie Historian, Outil Open Source Google permettant d'analyser les utilisateurs de la batterie à l'aide du rapport de bug Android .

Packages

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

Processus

Les rapports de bugs contiennent une énorme quantité de données pour les processus, y compris le démarrage et l'heure d'arrêt, la durée de l'environnement d'exécution, les services associés, le score oom_adj, etc. Pour en savoir plus sur la manière dont Android gère les processus, consultez Processus et les threads.

Déterminer l'environnement d'exécution du processus

La section procstats contient des statistiques complètes sur la durée et les services associés s'exécutent. Pour obtenir une réponse rapide et intelligible Pour le résumé, recherchez AGGREGATED OVER pour afficher les données 3 ou 24 dernières heures, puis recherchez Summary: pour afficher la liste de processus, la durée d'exécution de ces processus selon différentes priorités, et leurs Utilisation de la RAM au format min-average-max PSS/min-average-max USS.

Raisons pour lesquelles un processus est en cours d'exécution

La section dumpsys activity processes répertorie tous les rôles processus en cours d'exécution, classés par score oom_adj (Android indique en attribuant au processus une valeur oom_adj, qui peuvent être mises à jour de manière dynamique par ActivityManager). Le résultat est semblable à celui de un instantané de mémoire, mais inclut des données des informations sur ce qui entraîne l'exécution du processus. Dans l'exemple ci-dessous, les entrées en gras indiquent que le processus gms.persistent est en cours d'exécution avec la priorité vis (visible), car le processus système est lié son NetworkLocationService.

Analyses

Pour identifier les applications qui présentent des performances excessives, procédez comme suit : Recherches Bluetooth à basse consommation (BLE) :

  • Recherchez les messages de 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 de journal. Dans cet exemple, "24840" et "24851" sont le PID (ID du processus) et le TID (ID du thread).
  • Recherchez 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 application: https://play.google.com/store/apps/details?id=com.badapp

Remarque: Pour les appareils équipés d'Android 7.0, collecte des données pour les analyses BLE et associe ces activités avec l'application de lancement. Pour en savoir plus, consultez Low Energy (LE) et recherches Bluetooth.