L’utilitaire de consignation de journaux Logcat est un outil de ligne de commande inclus avec le SDK Android. Il permet d’afficher les messages du SE (Système d’exploitation) et les messages de journaux d’applications. Pendant la phase de développement, Logcat est indispensable lors de l’exécution d’une application afin de surveiller son activité et celle du SE Android sur un appareil. Le guide sur les statistiques VrApi fournit des informations détaillées pour l’interprétation des journaux VrApi de Logcat.
Présentation
Logcat est un outil de ligne de commande inclus dans le SE Android. Il peut être utilisé pendant l’exécution d’une application sur un appareil Meta Quest pour consulter les messages consignés de cette application et du SE Android, notamment :
Les messages système et Android, tels que l’état du matériel et les traces de pile figurant dans les messages d’erreur.
Les messages du SE Meta Horizon, tels que les journaux consignant l’heure de démarrage et d’arrêt d’une application, ainsi que l’heure de mise en place et de retrait du casque Quest.
Les messages relatifs aux applications Meta Quest en cours d’exécution, tels que les modifications des niveaux CPU et GPU, ainsi que les informations sur les performances des applications. Les développeur·ses d’applications peuvent aussi ajouter des journaux à leur application pour les consulter dans Logcat à l’aide de la classe Log Android.
Ces informations permettent d’identifier les problèmes de performances et de déterminer les causes à l’origine d’un plantage. Logcat permet aussi d’extraire des journaux d’applications ayant récemment fait l’objet d’un plantage afin d’essayer d’en identifier ces causes.
Logcat offre les avantages suivants : couramment utilisé par les développeur·ses Android, dépenses opérationnelles minimes et technologie agnostique lui permettant de s’adapter à n’importe quel moteur. Bien qu’il ne fournisse que des informations élémentaires, Logcat reste un outil utile de tri général des applications Meta Quest.
Recueillir des journaux Meta Quest avec Logcat
Les sections suivantes expliquent comment configurer Logcat, recueillir les journaux d’une application en cours d’exécution sur un appareil Meta Quest, voire consulter les journaux de plantage qui se sont produits lorsque Logcat n’était pas utilisé.
Utilisation basique
Pour utiliser Logcat, lancez un modèle de SE, établissez une connexion ADB (Android Debug Bridge) avec l’appareil Meta Quest via USB ou Wi-Fi, puis saisissez la commande suivante :
adb logcat
Si l’appareil est connecté et détecté, les journaux de sortie vont immédiatement commencer à s’afficher dans le modèle. La plupart du temps, la sortie brute générée est beaucoup trop détaillée pour être exploitable. Pour résoudre ce problème, Logcat prend en charge le filtrage par tags. Pour afficher un tag spécifique, saisissez la commande suivante :
adb logcat -s <tag>
Les exemples suivants montrent uniquement la sortie du tag VrApi, uniquement la sortie du tag PerformanceManager_ZSF et uniquement la sortie des deux tags :
Notez que Logcat garde en mémoire tampon les sorties récentes qui seront imprimées immédiatement à l’exécution. Pour effacer toutes les données figurant dans la mémoire tampon de Logcat, saisissez la commande suivante :
adb logcat -c
Notez que cette commande peut être suivie d’une autre. Pour afficher toutes les sorties du tag PerformanceManager_ZSF dès la saisie de la commande, saisissez ce qui suit :
Ces différents éléments représentent, dans l’ordre :
Statistique
Description
01-19 16:05:56.196
Horodatage de consignation. Remarque : étant donné que Logcat garde en mémoire tampon les sorties précédentes, cet horodatage peut être antérieur au début de l’impression des journaux.
2817
ID que le système d’exploitation a affecté au processus ayant généré ce journal.
3566
ID que le système d’exploitation a affecté au thread ayant généré ce journal.
I
Gravité de ce journal. Du niveau le plus bas au plus élevé : Verbose (Verbeux), Debug (Débogage), Info (Informations), Warning (Avertissement), Error (Erreur), Fatal (Fatal), Silent (Silencieux).
Consultez les définitions des statistiques Logcat pour en savoir plus sur l’interprétation des journaux VrApi et XrPerformanceManager de Logcat.
Utilisation de Logcat pour déterminer la cause d’un plantage
Logcat n’est pas toujours en cours d’exécution lors du plantage d’une application. Néanmoins, il conserve les sorties récentes en mémoire tampon et il est généralement possible d’y saisir une commande juste après la survenue d’un plantage, afin de capturer le journal contenant sa trace d’appel :
adb logcat > crash.log
Pour cela, saisissez simplement la commande ci-dessus, patientez pendant que le modèle copie la sortie mise en mémoire tampon dans le journal, puis fermez ADB (Ctrl+C dans une invite de commande Windows ou une invite de terminal macOS). Puis, saisissez "backtrace:" pour localiser dans le journal le début de la trace de la pile correspondant à la survenue du plantage.
Si trop de temps s’est écoulé et que le journal n’affiche aucune trace d’appel, saisissez la commande bugreport pour obtenir un fichier .zip contenant des journaux, des fichiers tombstone et d’autres données pour vous aider à analyser des plantages :
adb bugreport outputfile.zip
Le fichier sera enregistré dans le répertoire actuel de l’utilisateur·ice. Si aucun nom de sortie n’a été spécifié, il affichera alors sa date d’enregistrement.
Obtenir une meilleure trace de pile
La trace d’appel figurant dans une capture Logcat indique généralement la fonction dans laquelle s’est produit le plantage, sans aucun numéro de ligne. Pour en savoir plus sur un plantage, il convient d’installer le kit de développement natif (NDK pour Native Development Kit) Android. Une fois le NDK installé, l’utilitaire ndk-stack permet d’analyser l’état du journal Logcat, afin d’obtenir des informations plus détaillées sur l’état de la pile. Pour utiliser ndk-stack, saisissez la commande suivante :
ndk-stack -sym <path to symbol file> -dump <source log file> > stack.log
Par exemple, la commande suivante génère une trace de pile plus détaillée dans un fichier nommé stack.log en utilisant le chemin des symboles d’une version arm64-v8a et la trace de pile trouvée dans crash.log :