Malheureusement, MyApp s'est arrêté. Comment puis-je résoudre ça?
Je développe une application et chaque fois que je l'exécute, je reçois le message suivant:
Malheureusement, MyApp s'est arrêté.
Que puis-je faire pour résoudre ce problème?
À propos de cette question - manifestement inspirée par Qu'est-ce qu'une trace de pile et comment puis-je l'utiliser pour déboguer mes erreurs d'application? , de nombreuses questions indiquent que leur L’application s’est écrasée, sans autre détail. Cette question vise à expliquer aux novices Android les programmeurs comment résoudre eux-mêmes leurs problèmes ou poser les bonnes questions.
Cette réponse décrit le processus de récupération de la trace de pile. Vous avez déjà la trace de la pile? Consultez les traces de pile dans " Qu'est-ce qu'une trace de pile et comment puis-je l'utiliser pour déboguer les erreurs de mon application? "
Le problème
Votre demande a été abandonnée car un RuntimeException non capturé a été lancé.
Le plus commun d'entre eux est le NullPointerException .
Comment le résoudre?
Chaque fois qu'une application Android se bloque (ou toute application Java d'ailleurs), un Stack trace est écrit sur la console (dans ce cas, logcat). Cette trace de pile contient des informations essentielles pour résoudre votre problème.
Studio Android
Dans la barre inférieure de la fenêtre, cliquez sur le bouton Logcat. Sinon, vous pouvez appuyer sur alt+6. Assurez-vous que votre émulateur ou périphérique est sélectionné dans le panneau Devices. Ensuite, essayez de trouver la trace de la pile, qui est affichée en rouge. Logcat contient peut-être beaucoup d'éléments, vous devrez donc peut-être faire défiler un peu. Un moyen facile de trouver la trace de la pile est d'effacer le logcat (à l'aide de la corbeille à droite) et de laisser l'application se bloquer à nouveau.
J'ai trouvé la trace de la pile, et maintenant?
Yay! Vous êtes à mi-chemin pour résoudre votre problème.
Il vous suffit de déterminer ce qui a provoqué le blocage de votre application en analysant le suivi de la pile.
Consultez les traces de pile dans " Qu'est-ce qu'une trace de pile et comment puis-je l'utiliser pour déboguer les erreurs de mon application? "
Je ne peux toujours pas résoudre mon problème!
Si vous avez trouvé votre Exception et la ligne où il s'est produit, mais que vous ne savez toujours pas comment le réparer, n'hésitez pas à poser une question sur StackOverflow.
Essayez d’être aussi concis que possible: postez la trace de la pile et le code pertinent (par exemple, quelques lignes jusqu’à la ligne qui a lancé le Exception).
Vous pouvez utiliser outil ADB de Google pour obtenir Logcat file analyser le problème.
adb logcat > logcat.txt
ouvrez le fichier logcat.txt et cherchez le nom de votre application. Il devrait y avoir des informations sur les raisons de l'échec, le numéro de ligne, le nom de la classe, etc.
Tout d’abord, vous vérifiez le point où votre application est tombée en panne (Unfortunately, MyApp has stopped.). Pour cela, vous pouvez utiliser Log.e("TAG", "Message");. Cette ligne vous permet de voir le journal de vos applications dans logcat.
Après cela, vous trouvez à quel point votre application s’est arrêtée, il est très facile à résoudre à vos côtés.
Il suffit de vérifier l'erreur dans le journal du chat.
Vous obtenez l'option log chat de Eclipse:
fenêtre-> afficher la vue-> autres-> Android-> Logcat
Journal chat contient une erreur.
Sinon, vous pouvez également vérifier l'erreur en exécutant une application en mode débogage. D'abord, définissez le point d'arrêt après cela en faisant:
clic droit sur projet-> debug as-> application Android
Remarque: Cette réponse utilise Android Studio 2.2.2
Remarque 2: Je considère que votre appareil est correctement connecté.
La première chose que vous faites lorsque votre application se bloque est de regarder dans LogCat. Au bas de Android Studio, vous trouverez une barre d'outils avec une liste de menus:
Cliquez sur le "Moniteur Android" (celui que j'ai souligné dans l'image ci-dessus. ^)
Maintenant, vous obtiendrez quelque chose comme ça:
Remplacez "Verbose" par "Error". Les erreurs enregistrées ne seront alors plus affichées. Ne vous inquiétez pas de toutes ces erreurs (si vous les avez) maintenant.
D'accord. Maintenant, faites ce que vous avez fait pour bloquer votre application. Après le blocage de votre application, accédez à votre logcat. Vous devriez trouver un nouveau journal d'incidents contenant beaucoup de at:x.x.x: et Caused by: TrumpIsPresidentException par exemple. Accédez à cette instruction Caused by: dans votre logcat.
À côté de que Caused By:, il devrait exister une exception qui s'est produite. Dans mon cas, il s'agit d'une RuntimeException et dessous , une ligne contenant un bleu lien tel que:
Si ce Caused by: N'A PAS une ligne avec un texte bleu quelque part en dessous, recherchez un autre Caused by: qui le fait .
Cliquez sur ce lien bleu . Cela devrait vous mener là où le problème est survenu. Dans mon cas, c'était dû à cette ligne:
throw new RuntimeException();
Donc, maintenant je sais pourquoi il se plante. C'est parce que je lance l'exception moi-même. Ce fut une erreur évidente .
Cependant, supposons que j'ai une autre erreur:
Java.lang.NullPointerException
J'ai vérifié mon logcat, j'ai cliqué sur le lien bleu qu'il m'a donné et cela m'a pris ici:
mTextView.setText(myString);
Donc, maintenant je veux déboguer. Selon cette question StackOverflow , une exception NullPointerException indique que quelque chose est null.
Voyons donc ce qui est null . Il y a deux possibilités. Soit mTextView est nul, soit myString est nul. Pour le savoir, avant la ligne mTextView.setText(mString), j'ajoute ces deux lignes:
Log.d("AppDebug","mTextView is null: " + String.valueOf(mTextView == null);
Log.d("AppDebug","myString is null: " + String.valueOf(myString== null);
Maintenant, comme nous l'avons fait précédemment (nous avons changé Verose en Erreur), nous voulons changer "Erreur" en "Debug". Depuis que nous nous connectons par débogage. Voici toutes les méthodes du journal:
Log.
d means Debug
e means error
w means warning
v means verbose
i means information
wtf means "What a terrible failure". This is similar to Log.e
Donc, puisque nous avons utilisé Log.d, nous vérifions dans Debug. C'est pourquoi nous l'avons changé pour déboguer.
Avis Log.d a un premier paramètre, dans notre cas "AppDebug". Cliquez sur le menu déroulant "Aucun filtre" en haut à droite du logcat. Sélectionnez "Modifier la configuration du filtre", donnez un nom à votre filtre et, dans "Log Tag", mettez "App Debug". Cliquez sur OK". Maintenant, vous devriez voir deux lignes dans le logcat:
yourPackageNameAndApp: mTextView is null: true
yourPackageNameAndApp: myString is null: false
Alors maintenant, nous savons que mTextView est null.
J'observe mon code, maintenant je remarque quelque chose.
J'ai private TextView mTextView déclaré au sommet de ma classe. Mais je ne le définis pas.
En gros, j'ai oublié de le faire dans mon onCreate ():
mTextView = (TextView) findViewById(R.id.textview_id_in_xml);
C’est la raison pour laquelle mTextView est null, car j’ai oublié de dire à mon application ce qu’elle est. Alors j'ajoute cette ligne, lance mon application, et maintenant l'application ne plante pas.
Cette fenêtre contextuelle s'affiche uniquement lorsque vous recevez une exception irrécupérable dans votre code qui arrête l'exécution de l'application. Cela pourrait être n'importe quelle exception NullPointerException, OutOfMemoryException etc.
Le meilleur moyen de vérifier consiste à utiliser Logcat si vous développez toujours l'application dans Android studio, qui est un moyen rapide de lire le suivi de la pile et de déterminer la cause de l'application.
Si votre application est déjà en ligne, vous ne pouvez pas utiliser logcat. Donc, pour cela, vous pouvez implémenter Crashlytics pour vous fournir des rapports de bogues de toutes les exceptions qui se produisent.
Vérifiez votre message Logcat et consultez votre fichier Manifest. Il devrait manquer quelque chose comme définir le Activity,User permission`, etc.
Vous pouvez utiliser l'un de ces outils:
adb logcat
adb logcat> logs.txt (vous pouvez utiliser des éditeurs pour ouvrir et rechercher des erreurs.)
Eclipse logcat (s'il n'est pas visible dans Eclipse, accédez à Windows-> Afficher la vue-> Autres-> Android-> LogCat)
- Moniteur de débogage Android ou Android Moniteur de périphérique (commande de type surveiller ou ouvrir via l'interface utilisateur)
- Studio Android
Je suggère d'utiliser Android Debug Monitor , c'est bien. Parce qu'Eclipse se bloque lorsqu'il y a trop de journaux, et par le biais du filtre adb logcat et de toutes les difficultés.
Vous devez vérifier le Stack trace
Comment faire ça?
sur votre IDE Vérifiez les fenêtres de LOGCAT
Si vous ne voyez pas les fenêtres logcat, allez dans ce chemin et ouvrez-le
window->show view->others->Android->Logcat
si vous utilisez Google-Api, accédez à ce chemin
adb logcat> logcat.txt
Dans la méthode showToast () ci-dessous, vous devez passer un autre paramètre pour le contexte ou le contexte d'application, ce qui vous permet de l'essayer.
public void showToast(String error, Context applicationContext){
LayoutInflater inflater = getLayoutInflater();
View view = inflater.inflate(R.layout.custom_toast, (ViewGroup)
findViewById(R.id.toast_root));
TextView text = (TextView) findViewById(R.id.toast_error);
text.setText(error);
Toast toast = new Toast(applicationContext);
toast.setGravity(Gravity.TOP | Gravity.FILL_HORIZONTAL, 0, 0);
toast.setDuration(Toast.LENGTH_SHORT);
toast.setView(view);
toast.show();
}
Permettez-moi de partager une analyse Logcat de base lorsque vous rencontrez une fermeture forcée (lorsque l'application cesse de fonctionner).
DOCS
L'outil de base de Android pour collecter/analyser les journaux est le logcat.
HERE est la page Android à propos de logcat
Si vous utilisez Android Studio, vous pouvez également vérifier LINK .
Capture
Fondamentalement, vous pouvez capturer MANUELLEMENT logcat avec la commande suivante (ou simplement vérifier la fenêtre AndroidMonitor dans AndroidStudio):
adb logcat
Il y a beaucoup de paramètres que vous pouvez ajouter à la commande qui vous aide à filtrer et à afficher le message que vous voulez ... C'est personnel ... J'utilise toujours la commande ci-dessous pour obtenir l'horodatage du message:
adb logcat -v time
Vous pouvez rediriger la sortie vers un fichier et l’analyser dans un éditeur de texte.
Analyse
Si votre application se bloque, vous obtiendrez quelque chose comme:
07-09 08:29:13.474 21144-21144/com.example.khan.abc D/AndroidRuntime: Shutting down VM
07-09 08:29:13.475 21144-21144/com.example.khan.abc E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.example.khan.abc, PID: 21144
Java.lang.NullPointerException: Attempt to invoke virtual method 'void Android.support.v4.app.FragmentActivity.onBackPressed()' on a null object reference
at com.example.khan.abc.AudioFragment$1.onClick(AudioFragment.Java:125)
at Android.view.View.performClick(View.Java:4848)
at Android.view.View$PerformClick.run(View.Java:20262)
at Android.os.Handler.handleCallback(Handler.Java:815)
at Android.os.Handler.dispatchMessage(Handler.Java:104)
at Android.os.Looper.loop(Looper.Java:194)
at Android.app.ActivityThread.main(ActivityThread.Java:5631)
at Java.lang.reflect.Method.invoke(Native Method)
at Java.lang.reflect.Method.invoke(Method.Java:372)
at com.Android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.Java:959)
at com.Android.internal.os.ZygoteInit.main(ZygoteInit.Java:754)
07-09 08:29:15.195 21144-21144/com.example.khan.abc I/Process: Sending signal. PID: 21144 SIG: 9
Cette partie du journal vous montre beaucoup d'informations:
- Quand le problème est arrivé:
07-09 08:29:13.475
Il est important de vérifier quand le problème est survenu ... Vous pouvez trouver plusieurs erreurs dans un journal ... vous devez être sûr que vous vérifiez les messages appropriés :)
- Quelle application s'est écrasée:
com.example.khan.abc
De cette façon, vous savez quelle application est tombée en panne (pour être sûr de vérifier les journaux de votre message)
- Quelle erreur:
Java.lang.NullPointerException
Une erreur d'exception de pointeur NULL
- Informations détaillées sur l'erreur:
Attempt to invoke virtual method 'void Android.support.v4.app.FragmentActivity.onBackPressed()' on a null object reference
Vous avez essayé d'appeler la méthode onBackPressed() à partir d'un objet FragmentActivity. Cependant, cet objet était null quand vous l'avez fait.
Traçage de pile: Traçage de pile vous montre l'ordre d'appel de la méthode ... Parfois, l'erreur se produit dans la méthode appelante (et non dans la méthode appelée).
sur com.example.khan.abc.AudioFragment $ 1.onClick (AudioFragment.Java:125)
Une erreur s'est produite dans le fichier com.example.khan.abc.AudioFragment.Java, à l'intérieur de la méthode onClick() à la ligne: 125 (stacktrace indique la ligne où l'erreur s'est produite).
Il a été appelé par:
at Android.view.View.performClick(View.Java:4848)
Qui a été appelé par:
at Android.view.View$PerformClick.run(View.Java:20262)
qui a été appelé par:
at Android.os.Handler.handleCallback(Handler.Java:815)
etc....
Vue d'ensemble
Ce n’était qu’un aperçu ... Tous les journaux ne sont pas simples, etc. Il s’agit simplement de partager l’idée et de vous fournir une information de base ...
J'espère que je pourrai t'aider quelque part ... Cordialement
Utilisez le LogCat et essayez de trouver ce qui provoque le blocage de l'application.
Pour voir Logcat si vous utilisez Android Studio, appuyez sur ALT + 6 ou
si vous utilisez Eclipse alors Fenêtre -> Perspective ouverte -> Autres - LogCat
Allez dans le LogCat, dans le menu déroulant, sélectionnez erreur. Cela contiendra toutes les informations nécessaires pour vous aider à déboguer. Si cela ne vous aide pas, publiez le LogCat en tant que modification de votre question et quelqu'un vous aidera.
Si, pour une raison quelconque, votre application se bloque sans un bon tracé de pile, Essayez de le déboguer à partir de la première ligne et allez ligne par ligne jusqu’au crash. Ensuite, vous aurez réponse, quelle ligne vous pose problème. Vous pouvez évidemment l'envelopper dans try catch block et imprimer une sortie d'erreur.
Crash en cours de développement
Essayez mon outil préféré logview pour obtenir les journaux et les analyser au cours du développement.
Assurez-vous de marquer ./logview et ./lib/logview.jar comme exécutable lors de l'exécution sous Linux.
Si vous ne l'aimez pas, il existe de nombreuses alternatives lecteurs de journaux de bureau pour Android .
Crash à l'état sauvage
Intégrez un outil de signalement des incidents en temps réel tel que Firebase Crashlytics afin d’obtenir les traces de pile des exceptions non gérées survenues sur les appareils des utilisateurs.
Lire Comment libérer une application Buggy (et vivre pour raconter l'histoire) pour en savoir plus sur la gestion des bugs sur le terrain.
Vous pouvez également obtenir ce message d'erreur seul, sans trace de pile ni autre message d'erreur.
Dans ce cas, vous devez vous assurer que votre manifeste Android est correctement configuré (y compris toute fusion de manifeste se produisant à partir d'une bibliothèque et toute activité pouvant provenir d'une bibliothèque), et porter une attention particulière à la première activité affichée dans votre application dans vos fichiers manifestes.
Les gens font des erreurs et codent aussi.
Chaque fois que error se produit, vérifiez toujours avec le logcat avec le texte en couleur rouge. Cependant, vous pouvez trouver le problème réel en texte de couleur bleue avec soulignement dans le texte de couleur rouge.
Assurez-vous que si vous créez un nouveau activity, déclarez toujours le activity dans le fichier AndroidManifest.
Si vous ajoutez une autorisation, déclarez-la également dans le fichier AndroidMainifest.
Logcat - Pour vérifier les journaux lors de la phase de développement de Android Studio
Effacez initialement le Logcat et laissez l’application se bloquer à nouveau afin que vous ne puissiez obtenir que les détails du journal bloqués. Vous devez vérifier la trace de pile
Alors que, malheureusement, MyApp s'est arrêté. Il y a plusieurs raisons à cela. Vous pouvez vérifier même dans les journaux. Pour cela, vous pouvez utiliser le Log.e ("TAG", "Message");
Erreur commune lors du crash de l'application comme:
- Erreur de codage (mauvaise utilisation de mots-clés).
- Nom de propriété incompatible.
- Plugin non supporté (peut-être).
- Version incompatible (peut-être).
- Activité manquante dans le fichier AndroidManifest.
- Autorisation manquante dans le fichier AndroidManifest.
- La plus commune des NullPointerException.
- Déclaré mais non défini.
Pour résoudre l'erreur de blocage de l'application:
- Gardez à l’esprit les points ci-dessus et parcourez-les.
- Avec l'erreur, vous obtiendrez le nom du fichier également en bleu (cliquez dessus et passez au code de l'erreur en cours).
Tout d'abord, vous devez vérifier où et pourquoi votre application a été bloquée (Unfortunately, MyApp has stopped.). Avec l'aide de LOG, vous pouvez déterminer ce qui ne va pas.
Après cela, vous trouvez le point auquel votre application a été arrêtée pour résoudre ce problème.
Si vous n'avez pas de type de journal intéressant dans votre terminal (ou s'ils ne sont pas directement liés à votre application), peut-être que votre problème est dû à une bibliothèque native. Dans ce cas, vous devriez rechercher les fichiers "de désactivation" dans votre terminal.
L'emplacement par défaut des fichiers de désactivation dépend de chaque périphérique, mais si c'est le cas, vous aurez un journal indiquant: Tombstone written to: /data/tombstones/tombstone_06
Pour plus d'informations, consultez https://source.Android.com/devices/tech/debug .