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:
Malheureusement, MyApp s'est arrêté.
Que puis-je faire pour résoudre ce problème?
À propos de cette question - évidemment inspirée de Qu'est-ce qu'une trace de pile et comment puis-je l'utiliser pour déboguer mes erreurs d'application? , il y a beaucoup de questions indiquant que leur application a planté, sans plus de détails. Cette question vise à enseigner aux programmeurs Android novices comment essayer de résoudre eux-mêmes leurs problèmes ou poser les bonnes questions.
Réponses
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? Lisez les traces de pile dans " Qu'est-ce qu'une trace de pile et comment puis-je l'utiliser pour déboguer mes erreurs d'application? "
Le problème
Votre application s'est fermée car un non intercepté a RuntimeExceptionété jeté.
Le plus courant est le NullPointerException.
Comment le résoudre?
Chaque fois qu'une application Android plante (ou n'importe quelle application Java d'ailleurs), un Stack traceest écrit dans la console (dans ce cas, logcat). Cette trace de pile contient des informations vitales pour résoudre votre problème.
Studio Android
Dans la barre inférieure de la fenêtre, cliquez sur le Logcatbouton. Vous pouvez également appuyer sur alt+ 6. Assurez-vous que votre émulateur ou périphérique est sélectionné dans le Devicespanneau. Ensuite, essayez de trouver la trace de la pile, qui est affichée en rouge. Il peut y avoir beaucoup de choses connectées à logcat, vous devrez peut-être faire défiler un peu. Un moyen simple de trouver la trace de la pile consiste à effacer le logcat (à l'aide de la corbeille à droite) et à laisser l'application se bloquer à nouveau.
J'ai trouvé la trace de la pile, et maintenant?
Yay! Vous êtes à mi-chemin de la résolution de votre problème.
Il vous suffit de découvrir ce qui a provoqué le blocage de votre application en analysant la trace de la pile.
Lisez les traces de pile dans " Qu'est-ce qu'une trace de pile et comment puis-je l'utiliser pour déboguer mes erreurs d'application? "
Je n'arrive toujours pas à résoudre mon problème!
Si vous avez trouvé votre Exceptionet la ligne où cela s'est produit et que vous ne savez toujours pas comment le résoudre, 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 correspondant (par exemple quelques lignes jusqu'à la ligne qui a jeté le Exception).
Vous pouvez utiliser l'outil de la BAD de Google pour obtenir Logcat filed'analyser la question.
adb logcat > logcat.txt
ouvrez le logcat.txtfichier et recherchez le nom de votre application. Il devrait y avoir des informations sur la raison de l'échec, le numéro de ligne, le nom de la classe, etc.
Tout d'abord, vous vérifiez à quel point votre application s'est plantée ( Unfortunately, MyApp has stopped.). Pour cela, vous pouvez utiliser Log.e("TAG", "Message");, en utilisant cette ligne, vous pouvez voir votre journal d'application 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.
Vérifiez simplement l'erreur dans le chat de journal.
Vous obtenez l'option log cat dans eclipse:
fenêtre-> afficher la vue-> autres-> Android-> Logcat
Le chat du journal contient une erreur.
Sinon, vous pouvez également vérifier l'erreur en exécutant une application en mode débogage. Définissez d'abord le point d'arrêt après cela en faisant:
clic droit sur projet-> déboguer comme-> application Android
Remarque: cette réponse utilise Android Studio 2.2.2
Remarque 2: je considère que votre appareil est connecté avec succès.
La première chose que vous faites lorsque votre application se bloque est de regarder dans LogCat, au bas d'Android Studio, il y a une barre d'outils avec une liste de menus:
Cliquez sur "Android Monitor" (celui que j'ai souligné dans l'image ci-dessus. ^)
Maintenant, vous obtiendrez quelque chose comme ceci:
Remplacez " Verbose" par " Error" Maintenant, il ne montrera que les erreurs enregistré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 planter votre application. Une fois votre application plantée, accédez à votre logcat. Vous devriez trouver un nouveau journal des pannes contenant beaucoup de at:x.x.x: et Caused by: TrumpIsPresidentExceptionpar exemple. Accédez à cette Caused by:déclaration dans votre logcat.
À côté de cela Caused By:, il devrait y avoir l'exception qui s'est produite. Dans mon cas, c'est un RuntimeExceptionet en dessous il devrait y avoir une ligne qui contient un lien bleu tel que:
Si celaCaused by: N'A PAS de ligne avec un texte bleu quelque part en dessous, cherchez une autre Caused by:qui en a.
Cliquez sur ce lien bleu . Cela devrait vous amener là où le problème est survenu. Dans mon cas, c'était à cause de cette ligne:
throw new RuntimeException();
Alors, maintenant je sais pourquoi ça plante. C'est parce que je lance moi-même l'exception. C'était une erreur évidente .
Cependant, disons 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 amené ici:
mTextView.setText(myString);
Donc, maintenant je veux déboguer. Selon cette question StackOverflow , une NullPointerException dit que quelque chose est null.
Alors, découvrons ce qui est nul . Il y a deux possibilités. Soit mTextViewest nul, soit myStringest nul. Pour le savoir, avant la mTextView.setText(mString)ligne, 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 Error), nous voulons changer "Error" en "Debug". Puisque nous nous connectons par débogage. Voici toutes les méthodes de journalisation:
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, depuis que nous l'avons utilisé Log.d, nous enregistrons Debug. C'est pourquoi nous l'avons changé en débogage.
Remarque Log.da 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
Nous savons donc maintenant que mTextView est nul.
J'observe mon code, maintenant je remarque quelque chose.
J'ai private TextView mTextViewdéclaré en tête de ma classe. Mais je ne le définis pas.
Fondamentalement, j'ai oublié de le faire dans mon onCreate ():
mTextView = (TextView) findViewById(R.id.textview_id_in_xml);
C'est pourquoi mTextViewc'est nul, car j'ai oublié de dire à mon application de quoi il s'agit. J'ajoute donc cette ligne, j'exécute mon application, et maintenant l'application ne plante pas.
Cette fenêtre contextuelle s'affiche uniquement lorsque vous obtenez une exception fatale dans votre code qui arrête l'exécution de l'application. Cela peut être n'importe quelle exception NullPointerException, OutOfMemoryExceptionetc.
Le meilleur moyen de vérifier est via Logcat si vous développez toujours l'application dans le studio Android, ce qui est un moyen rapide de lire la trace de la pile et de vérifier 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 Crashlyticspour vous fournir des rapports de bogue de toute exception qui se produit.
Vérifiez votre Logcatmessage et consultez votre Manifestfichier. Il devrait y avoir quelque chose qui manque comme la définition de l' Activity,autorisation utilisateur`, 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, allez dans Windows-> Afficher la vue-> Autres-> Android-> LogCat)
Android Debug Monitor ou Android Device Monitor (tapez le moniteur de commande ou ouvrez via l'interface utilisateur)
- Studio Android
Je suggère d'utiliser Android Debug Monitor , c'est bien. Parce que l'éclipse se bloque lorsque trop de journaux sont là, et à travers le filtre adb logcat et tout est difficile.
Vous devez vérifier le Stack trace
Comment faire ça?
sur votre IDE Vérifiez les fenêtres du formulaire LOGCAT
Si vous ne voyez pas les fenêtres logcat, allez sur 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 en le faisant, vous pouvez 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 de base de Logcat lorsque vous rencontrez une fermeture forcée (lorsque l'application cesse de fonctionner).
DOCS
L'outil de base d'Android pour collecter / analyser les journaux est le logcat.
ICI est la page Android sur logcat
Si vous utilisez Android Studio, vous pouvez également vérifier ce LIEN .
Capturer
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.
en cours d'analyse
Si votre application plante, 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 présente de nombreuses informations:
- Lorsque le problème est survenu:
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 bons messages :)
- Quelle application a planté:
com.example.khan.abc
De cette façon, vous savez quelle application a planté (pour être sûr que vous vérifiez les journaux concernant 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 une méthode à onBackPressed()partir d'un FragmentActivityobjet. Cependant, cet objet était nullquand vous l'avez fait.
Stack Trace: Stack Trace 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).
à 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 onClick()méthode à la ligne: 125(stacktrace montre 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....
Aperçu
Ce n'était qu'un aperçu ... Tous les journaux ne sont pas simples mais l'erreur pose un problème spécifique et le verbeux montre tous les problèmes ... C'est juste pour partager l'idée et vous fournir des informations d'entrée de gamme ...
J'espère que je pourrais vous aider d'une manière ou d'une autre ... Cordialement
Utilisez le LogCat et essayez de trouver ce qui cause le plantage de l'application.
Pour voir Logcat si vous utilisez Android Studio, appuyez sur ALT + 6 ou
si vous utilisez Eclipse puis Window -> Open Perspective -> Other - LogCat
Accédez au LogCat, dans le menu déroulant, sélectionnez l'erreur. Celui-ci contiendra toutes les informations requises pour vous aider à déboguer. Si cela ne vous aide pas, postez le LogCat en tant que modification de votre question et quelqu'un vous aidera.
Si votre application se bloque pour une raison quelconque sans un bon stacktrace. Essayez de le déboguer à partir de la première ligne et continuez ligne par ligne jusqu'à ce que le crash se produise. Ensuite, vous aurez une réponse, quelle ligne vous cause des problèmes. Vous pouvez probablement l'encapsuler dans le bloc try catch et imprimer la sortie d'erreur.
Vous pouvez également obtenir ce message d'erreur seul, sans aucune trace de pile ni aucun 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é qui proviendrait d'une bibliothèque), et accorder une attention particulière à la première activité affichée dans votre application dans vos fichiers manifestes .
Crash pendant le développement
Essayez mon outil préféré logview pour obtenir les journaux et les analyser pendant le développement.
Assurez-vous de marquer ./logviewet ./lib/logview.jarcomme exécutable lors de l'exécution sous Linux.
Si vous ne l'aimez pas, il existe de nombreuses visionneuses de journaux de bureau alternatives pour Android .
Crash dans la nature
Intégrez un outil de rapport de plantage en temps réel tel que Firebase Crashlytics afin d'obtenir des traces d'exceptions non gérées sur les appareils des utilisateurs.
Lisez Comment publier une application de buggy (et vivre pour raconter l'histoire) pour en savoir plus sur la gestion des bogues sur le terrain.
Les gens font des erreurs, et donc le codage aussi.
Chaque fois que errorcela se produit, vérifiez toujours avec le logcat avec le texte en couleur rouge, mais vous pouvez trouver le vrai problème dans le texte de couleur bleue avec souligné dans ce texte de couleur rouge.
Assurez-vous que si vous créez un nouveau activity, déclarez toujours le activitydans le AndroidManifestfichier.
Si vous ajoutez une autorisation, déclarez-la également dans le AndroidMainifestfichier.
Logcat - Pour vérifier les journaux dans la phase de développement d'Android Studio
Initialement, effacez le Logcat et laissez l'application se bloquer à nouveau afin de ne pouvoir obtenir que les détails du journal en panne. Vous devez vérifier la trace de la pile
Alors que, malheureusement, MyApp s'est arrêté. Il y a plusieurs raisons à cela. Vous pouvez vérifier la même chose dans les journaux. Pour cela, vous pouvez utiliser le Log.e ("TAG", "Message");
Erreur courante lors d'un crash d'application comme:
- Erreur de codage (mauvaise utilisation des mots-clés).
- Nom de propriété incompatible.
- Plug-in non pris en charge (peut-être).
- Version incompatible (peut-être).
- Activité manquante dans le fichier AndroidManifest.
- Autorisation manquante dans le fichier AndroidManifest.
- NullPointerException la plus courante.
- Déclaré mais non défini.
Pour résoudre l'erreur de plantage de l'application:
- Gardez à l'esprit les points ci-dessus et parcourez-les.
- Avec l'erreur, vous obtiendrez le nom du fichier également en couleur bleue (cliquez dessus et passez au code en cas d'erreur).
Tout d'abord, vous devez vérifier où et pourquoi votre application a été plantée. (Unfortunately, MyApp has stopped.).Avec l'aide de LOG, vous pouvez comprendre ce qui n'a pas fonctionné.
Après cela, vous trouvez à quel point votre application s'est arrêtée, corrigez cela à partir de votre point.
Si vous n'avez aucun type de journal intéressant dans votre terminal (ou s'ils ne sont pas directement liés à votre application), votre problème est peut-être dû à une bibliothèque native. Dans ce cas, vous devriez rechercher les fichiers "tombstone" dans votre terminal.
L'emplacement par défaut des fichiers tombstone 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 .
L'exécution de cette commande dans le terminal peut également aider à trouver le problème:
gradlew build > log.txt 2>details.txt
alors vous devriez aller à l'emplacement du fichier gradlew dans les deux fichiers journaux ci-dessus.