Desafortunadamente, MyApp se ha detenido. ¿Como puedo resolver esto?
Estoy desarrollando una aplicación y cada vez que la ejecuto, recibo el mensaje:
Desafortunadamente, MyApp se ha detenido.
¿Qué puedo hacer para solucionar esto?
Acerca de esta pregunta, obviamente inspirada en ¿Qué es un seguimiento de pila y cómo puedo usarlo para depurar los errores de mi aplicación? , hay muchas preguntas que indican que su aplicación se ha bloqueado, sin más detalles. Esta pregunta tiene como objetivo instruir a los programadores de Android novatos sobre cómo intentar solucionar sus problemas por sí mismos o hacer las preguntas correctas.
Respuestas
Esta respuesta describe el proceso de recuperación del seguimiento de la pila. ¿Ya tienes el seguimiento de la pila? Lea sobre los seguimientos de la pila en " ¿Qué es un seguimiento de la pila y cómo puedo usarlo para depurar los errores de mi aplicación? "
El problema
Su aplicación se cerró porque RuntimeException
se lanzó un mensaje no detectado .
El más común de estos es el NullPointerException
.
¿Cómo resolverlo?
Cada vez que una aplicación de Android falla (o cualquier aplicación de Java para el caso), Stack trace
se escribe a en la consola (en este caso, logcat). Este seguimiento de pila contiene información vital para resolver su problema.
Estudio de Android
En la barra inferior de la ventana, haga clic en el Logcat
botón. Alternativamente, puede presionar alt+ 6. Asegúrese de que su emulador o dispositivo esté seleccionado en el Devices
panel. A continuación, intente encontrar el rastro de la pila, que se muestra en rojo. Es posible que haya muchas cosas registradas en logcat, por lo que es posible que deba desplazarse un poco. Una manera fácil de encontrar el rastro de la pila es borrar el logcat (usando la papelera de reciclaje a la derecha) y dejar que la aplicación se bloquee nuevamente.
He encontrado el rastro de la pila, ¿y ahora qué?
¡Hurra! Estás a medio camino de resolver tu problema.
Solo necesita averiguar qué hizo exactamente que su aplicación se bloqueara, analizando el seguimiento de la pila.
Lea sobre los seguimientos de la pila en " ¿Qué es un seguimiento de la pila y cómo puedo usarlo para depurar los errores de mi aplicación? "
¡Todavía no puedo resolver mi problema!
Si ha encontrado su Exception
línea y la línea donde ocurrió, y aún no puede averiguar cómo solucionarlo, no dude en hacer una pregunta en StackOverflow.
Trate de ser lo más conciso posible: publique el seguimiento de la pila y el código relevante (por ejemplo, unas pocas líneas hasta la línea que arrojó el Exception
).
Puede utilizar la herramienta ADB de Google para obtener Logcat file
para analizar el tema.
adb logcat > logcat.txt
abra el logcat.txt
archivo y busque el nombre de su aplicación. Debe haber información sobre por qué falló, el número de línea, el nombre de la clase, etc.
Primero, comprueba en qué punto se ha bloqueado tu aplicación ( Unfortunately, MyApp has stopped.
). Para ello, puede utilizar Log.e("TAG", "Message");
, utilizando esta línea, puede ver el registro de su aplicación en logcat.
Después de eso, averigua en qué punto se detuvo su aplicación y es muy fácil de resolver a su lado.
Simplemente verifique el error en log cat.
Obtienes la opción log cat de en eclipse:
ventana-> mostrar vista-> otros-> Android-> Logcat
El gato de registro contiene un error.
De lo contrario, también puede verificar el error ejecutando una aplicación en modo de depuración. Primero establezca el punto de interrupción después de eso haciendo:
haga clic derecho en proyecto-> depurar como-> aplicación de Android
Nota: esta respuesta usa Android Studio 2.2.2
Nota 2: Estoy considerando que su dispositivo está conectado correctamente.
Lo primero que hace cuando su aplicación falla es mirar en LogCat, en la parte inferior de Android Studio hay una barra de herramientas con una lista de menús:
Haga clic en el "Monitor de Android" (el que subrayé en la imagen de arriba. ^)
Ahora, obtendrás algo como esto:
Cambie " Verbose
" a " Error
" Ahora solo le mostrará los errores registrados. No se preocupe por todos estos errores (si los tiene) ahora.
Okay. Ahora, haga lo que hizo para bloquear su aplicación. Después de que su aplicación se bloquee, vaya a su logcat. Debería encontrar un nuevo registro de fallos que tenga muchos at:x.x.x
: y, Caused by: TrumpIsPresidentException
por ejemplo. Vaya a esa Caused by:
declaración en su logcat.
Junto a eso Caused By:
, debería estar la excepción que sucedió. En mi caso, es una RuntimeException
y debajo debería haber una línea que contenga un enlace azul como:
Si eseCaused by:
NO tiene una línea con un texto azul en algún lugar debajo, busque otro Caused by:
que sí lo tenga .
Haga clic en ese enlace azul . Debería llevarlo al lugar donde ocurrió el problema. En mi caso, se debió a esta línea:
throw new RuntimeException();
Entonces, ahora sé por qué está fallando. Es porque yo mismo lanzo la excepción. Este fue un error obvio .
Sin embargo, digamos que tengo otro error:
java.lang.NullPointerException
Revisé mi logcat, hice clic en el enlace azul que me dio y me llevó aquí:
mTextView.setText(myString);
Entonces, ahora quiero depurar. De acuerdo con esta pregunta de StackOverflow , una NullPointerException dice que algo es null
.
Entonces, averigüemos qué es nulo . Hay dos posibilidades. O mTextView
es nulo o myString
es nulo. Para averiguarlo, antes de la mTextView.setText(mString)
línea, agrego estas dos líneas:
Log.d("AppDebug","mTextView is null: " + String.valueOf(mTextView == null);
Log.d("AppDebug","myString is null: " + String.valueOf(myString== null);
Ahora, como hicimos anteriormente (cambiamos Verose a Error), queremos cambiar "Error" a "Debug". Dado que estamos registrando mediante depuración. Aquí están todos los métodos de registro:
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
Entonces, desde que usamos Log.d
, estamos revisando Debug. Por eso lo cambiamos para depurar.
Notice Log.d
tiene un primer parámetro, en nuestro caso "AppDebug". Haga clic en el menú desplegable "Sin filtros" en la parte superior derecha del logcat. Seleccione "Editar configuración de filtro", asigne un nombre a su filtro y en "Etiqueta de registro" ponga "Depuración de la aplicación". Haga clic en Aceptar". Ahora, debería ver dos líneas en el logcat:
yourPackageNameAndApp: mTextView is null: true
yourPackageNameAndApp: myString is null: false
Entonces ahora sabemos que mTextView es nulo.
Observo mi código, ahora noto algo.
Me he private TextView mTextView
declarado en la parte superior de mi clase. Pero no lo estoy definiendo.
Básicamente, olvidé hacer esto en mi onCreate ():
mTextView = (TextView) findViewById(R.id.textview_id_in_xml);
Por eso mTextView
es que es nulo, porque olvidé decirle a mi aplicación qué es. Así que agrego esa línea, ejecuto mi aplicación y ahora la aplicación no falla.
Esta ventana emergente solo se muestra cuando obtiene una excepción fatal en su código que detiene la ejecución de la aplicación. Podría ser cualquier excepción NullPointerException
, OutOfMemoryException
etc.
La mejor manera de verificar es a través de Logcat si aún está desarrollando la aplicación en Android Studio, que es una forma rápida de leer el seguimiento de la pila y verificar la causa de la aplicación.
Si su aplicación ya está activa, no puede usar logcat . Entonces, para eso, puede implementar Crashlytics
para proporcionarle informes de errores de cualquier excepción que ocurra.
Revise su Logcat
mensaje y vea su Manifest
archivo. Debería faltar algo como definir el Activity,
permiso de usuario`, etc.
Puede utilizar cualquiera de estas herramientas:
adb logcat
adb logcat> logs.txt (puede usar editores para abrir y buscar errores).
eclipse logcat (si no es visible en eclipse, vaya a Windows-> Mostrar vista-> Otros-> Android-> LogCat)
Monitor de depuración de Android o Monitor de dispositivo Android (escriba comando monitor o abra a través de la interfaz de usuario)
- Estudio de Android
Sugiero usar Android Debug Monitor , es bueno. Porque eclipse se cuelga cuando hay demasiados registros, y a través del filtro adb logcat y todo es difícil.
Tienes que comprobar el Stack trace
¿Como hacer eso?
en su IDE Verifique las ventanas del formulario LOGCAT
Si no puede ver las ventanas de logcat, vaya a esta ruta y ábrala
window->show view->others->Android->Logcat
si está utilizando Google-Api, vaya a esta ruta
adb logcat> logcat.txt
En el método showToast () a continuación, debe pasar otro parámetro para el contexto o el contexto de la aplicación para que pueda probarlo.
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();
}
Permíteme compartir un análisis básico de Logcat para cuando te encuentres con un cierre forzado (cuando la aplicación deja de funcionar).
DOCS
La herramienta básica de Android para recopilar / analizar registros es el logcat.
AQUÍ está la página de Android sobre logcat
Si usa Android Studio, también puede verificar este ENLACE .
Capturando
Básicamente, puede capturar logcat MANUALMENTE con el siguiente comando (o simplemente verifique la ventana de AndroidMonitor en AndroidStudio):
adb logcat
Hay muchos parámetros que puede agregar al comando que le ayudan a filtrar y mostrar el mensaje que desea ... Esto es personal ... Siempre uso el comando a continuación para obtener la marca de tiempo del mensaje:
adb logcat -v time
Puede redirigir la salida a un archivo y analizarlo en un editor de texto.
Analizando
Si tu aplicación falla, obtendrás algo como:
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
Esta parte del registro le muestra mucha información:
- Cuando sucedió el problema:
07-09 08:29:13.475
Es importante verificar cuándo ocurrió el problema ... Puede encontrar varios errores en un registro ... debe asegurarse de estar revisando los mensajes correctos :)
- Qué aplicación falló:
com.example.khan.abc
De esta manera, sabrá qué aplicación falló (para asegurarse de que está revisando los registros sobre su mensaje)
- Qué ERROR:
java.lang.NullPointerException
Un error de excepción de puntero nulo
- Información detallada sobre el error:
Attempt to invoke virtual method 'void android.support.v4.app.FragmentActivity.onBackPressed()' on a null object reference
Intentaste llamar al método onBackPressed()
desde un FragmentActivity
objeto. Sin embargo, ese objeto fue null
cuando lo hiciste.
Stack Trace: Stack Trace muestra el orden de invocación del método ... A veces, el error ocurre en el método de llamada (y no en el método llamado).
en com.example.khan.abc.AudioFragment $ 1.onClick (AudioFragment.java:125)
Se produjo un error en el archivo com.example.khan.abc.AudioFragment.java
, dentro del onClick()
método en la línea: 125
(stacktrace muestra la línea en la que ocurrió el error)
Fue llamado por:
at android.view.View.performClick(View.java:4848)
Que fue llamado por:
at android.view.View$PerformClick.run(View.java:20262)
que fue llamado por:
at android.os.Handler.handleCallback(Handler.java:815)
etc ....
Visión general
Esto fue solo una descripción general ... No todos los registros son simples, pero el error da un problema específico y el detalle muestra todos los problemas ... Es solo para compartir la idea y brindarle información de nivel de entrada ...
Espero poder ayudarte de alguna manera ... Saludos
Utilice LogCat e intente encontrar la causa del bloqueo de la aplicación.
Para ver Logcat si utiliza Android Studio y luego Presione ALT + 6 o
si usa Eclipse, entonces Ventana -> Perspectiva abierta -> Otro - LogCat
Vaya al LogCat, en el menú desplegable seleccione error. Esto contendrá toda la información requerida para ayudarlo a depurar. Si eso no ayuda, publique LogCat como una edición de su pregunta y alguien lo ayudará.
Si su aplicación por algún motivo falla sin un buen stacktrace. Intente depurarlo desde la primera línea y vaya línea por línea hasta que se bloquee. Entonces tendrás la respuesta, qué línea te está causando problemas. Probablemente, podría envolverlo en el bloque try catch e imprimir la salida del error.
También puede obtener este mensaje de error por sí solo, sin ningún rastro de pila ni ningún otro mensaje de error.
En este caso, debe asegurarse de que su manifiesto de Android esté configurado correctamente (incluida cualquier fusión de manifiesto que se produzca desde una biblioteca y cualquier actividad que provenga de una biblioteca), y prestar especial atención a la primera actividad que se muestra en su aplicación en sus archivos de manifiesto .
Crash durante el desarrollo
Pruebe mi herramienta favorita, logview, para obtener los registros y analizarlos durante el desarrollo.
Asegúrese de marcar ./logview
y ./lib/logview.jar
como ejecutable cuando se ejecuta en Linux.
Si no le gusta, hay muchos visores de registro de escritorio alternativos para Android .
Choque en la naturaleza
Integre una herramienta de informes de fallas en tiempo real, como Firebase Crashlytics , para obtener seguimientos de las excepciones no controladas que ocurrieron en los dispositivos de los usuarios.
Lea Cómo lanzar una aplicación con errores (y vivir para contar la historia) para saber más sobre cómo manejar errores en el campo.
La gente comete errores y, por tanto, también codifica.
Cuando error
ocurra algo, siempre consulte con Logcat con el texto en color rojo, sin embargo, puede encontrar el problema real en el texto en color azul con subrayado en ese texto en color rojo.
Asegúrese de que si crea uno nuevo activity
, siempre declare el activity
en el AndroidManifest
archivo.
Si agrega Permiso, declare también en el AndroidMainifest
archivo.
Logcat : para comprobar los registros en la fase de desarrollo de Android Studio
Inicialmente, borre el Logcat y deje que la aplicación se bloquee nuevamente para que solo pueda obtener los detalles del registro bloqueado. Tienes que comprobar el seguimiento de la pila
Mientras, Desafortunadamente, MyApp se ha detenido. Hay muchas razones para ello. Puede comprobarlo en los registros. Para ello, puede utilizar Log.e ("TAG", "Mensaje");
Error común durante el bloqueo de la aplicación como:
- Error de codificación (uso incorrecto de palabras clave).
- No coincide el nombre de la propiedad.
- Complemento no compatible (tal vez).
- Versión no coincidente (tal vez).
- Falta actividad en el archivo AndroidManifest.
- Falta el permiso en el archivo AndroidManifest.
- NullPointerException más común.
- Declarado pero no definido.
Para resolver el error de bloqueo de la aplicación:
- Tenga en cuenta los puntos anteriores y revíselo.
- Con el error, obtendrá el nombre del archivo también en color azul (haga clic en ellos y salte al código si se produce el error).
Primero, debe verificar dónde y por qué se bloqueó su aplicación. (Unfortunately, MyApp has stopped.).
Con la ayuda de LOG
, puede averiguar qué salió mal.
Después de eso, encontrará en qué punto su aplicación ha dejado de solucionarlo desde su punto.
Si no tiene ningún tipo de registro interesante en su terminal (o no están directamente relacionados con su aplicación), tal vez su problema se deba a una biblioteca nativa. En ese caso, debe verificar los archivos "tombstone" dentro de su terminal.
La ubicación predeterminada para los archivos de desecho depende de cada dispositivo, pero si ese es el caso, tendrá un registro que dice: Tombstone written to: /data/tombstones/tombstone_06
Para obtener más información, consulte https://source.android.com/devices/tech/debug .
También ejecutar este comando en la terminal puede ayudar a encontrar el problema:
gradlew build > log.txt 2>details.txt
luego debe ir a la ubicación del archivo gradlew en los dos archivos de registro anteriores.