¿Cómo saber por qué se bloqueó una aplicación?

Regularmente obtengo el infame e inútil mensaje "desafortunadamente crappyApp ha dejado de funcionar". ¿Cómo averiguar qué salió realmente mal? Supongo que hay un rastro de pila en alguna parte, aunque idealmente me gustaría modificar el mensaje inútil en sí mismo si eso es posible en un dispositivo rooteado.

Para empezar, tenemos el tag-wiki de solución de problemas ;)

Respuestas (4)

Simplemente puede ver el seguimiento de la pila de fallas después de que ocurra una falla. Use el comando ADB a continuación,

adb logcat -b crash #default
adb -d logcat -b crash #show from device when multiple device
adb -s logcat -b crash #show from simulator when multiple device

Existen múltiples formas de obtener información útil. Pero como señaló Dan , las soluciones en el dispositivo requerirán root (comenzando con JellyBean) y soluciones ADB fuera del dispositivo:

  • adb logcatya se describió en la respuesta de Dan . Para obtener más detalles, puede consultar nuestra wiki de etiquetas de registro .
  • adb bugreport > report.txtbrinda información muy detallada, incluidos detalles de las herramientas dumpsys, dumpstatey . logcatSe pueden encontrar varias herramientas para facilitar el análisis de su salida, por ejemplo, en las respuestas a ¿Mejor método para ver la salida de "adb bugreport"? en nuestro sitio hermano.
  • hay herramientas para instalar en su computadora que utilizan lo anterior (o al menos partes de él), como QtADB (para Linux, Mac y Windows)
  • hay aplicaciones de Android como Bug Reporter ; pero como se señaló, la mayoría de ellos requerirá root. Sin embargo, Bug Report Reader afirma leer los registros del sistema (logcat, dumpsys, dmesg, top y mucho más) en su dispositivo, sin root , por lo que podría valer la pena intentarlo.

En la mayoría de los casos, si la depuración de USB está activada, puede usar adb logcatpara ver la salida de excepción. Esto generalmente incluye un seguimiento de la pila, pero eso no suele ser útil a menos que tenga el código fuente de la aplicación. De todos modos, el desarrollador de la aplicación probablemente te lo agradecerá si la incluyes en cualquier informe de error.

Gracias, preferiría una solución nativa directamente en el dispositivo si es posible. buen punto sobre la utilidad, ¿no incluye la traza al menos excepciones java con nombres sensatos? ¿O dalvik los ofusca?
Hay aplicaciones para leer el registro desde el dispositivo (busque logcat en Google Play ), pero en Jelly Bean y versiones posteriores, las aplicaciones no pueden leer los registros de otras, por lo que es posible que deba rootear su dispositivo para hacer esto. El seguimiento incluye nombres de excepción de Java, pero NullPointerExceptionen realidad no le dice mucho a menos que sea el desarrollador de la aplicación.
buen punto sobre esa excepción: / ya que rooteé mi dispositivo de todos modos, esperaba una forma más cómoda que logcat, aunque eso es mejor que nada ...

Lea los archivos /data/anr/que significan "aplicaciones que no responden". yo sueloadb shell cat /data/anr/$FILE

Habrá una para cada aplicación que se cierre a la fuerza o que no responda por algún motivo.

Al mirar /data/anr/ en un explorador de archivos raíz, solo hay un archivo traces.txt que se modificó hace tres días (aunque una aplicación falló hoy), y parece contener solo fallas del sistema, no fallas de la aplicación. ¿Hay otra forma de ver esos rastros de aplicaciones?
¿Cómo saber por qué se bloqueó una aplicación?
RespuestasAquíPolítica de privacidad1y, 0v