Problemas para acceder a los registros de mensajes en Jelly Bean con aLogcat

Resumen

He tenido problemas para acceder a los mensajes de registro de K9 usando aLogcat, consulte a continuación para obtener más detalles. Lo que quisiera saber es:

  • ¿Por qué no aparecen mensajes de registro de K9 en el visor de registros de aLogcat?
  • ¿Alguien tiene alguna sugerencia sobre cómo puedo ver el texto completo de los errores que ocurren al intentar sincronizar mis carpetas K9?
  • ¿Podría haber cambiado algo en Jelly Bean que hizo que el registro de K9 dejara de funcionar?
  • Dado que parece que aLogcat muestra muy pocos mensajes en general, ¿ha cambiado algo en Jelly Bean que podría significar que ya no puede acceder a todos los mensajes?

Detalle

Recientemente he tenido problemas de conexión con K9. Mis carpetas no se sincronizan y la lista de carpetas termina llena de errores de socket ( libcore.io.ErrnoException:) o errores de ssl ( javex.net.ssl.SSLException:), etc. donde debería estar la última hora verificada . Recibo diferentes mensajes según el problema que se presente en ese momento, pero no puedo ver el texto completo del mensaje de error, por lo que es difícil adivinar cuál podría ser la causa.

Pensando que los archivos de registro podrían contener más información, seguí las instrucciones en Grabación de un registro de depuración , habilité el registro de depuración en K9, instalé aLogcat e intenté ver los registros. Lamentablemente, cualquiera que sea el búfer de registro que seleccione ( Principal , Eventos o Radio ), parece que no hay mensajes de K9.

Si agrego el (k9|AndroidRuntime)filtro de expresiones regulares sugerido, no veo nada en ninguno de los registros. Si lo elimino, Main contiene principalmente mensajes de recolección de basura, Events parece contener principalmente mensajes de aLogcat y aún no he visto un mensaje de registro en Radio .

Si hace alguna diferencia, estoy usando un Nexus 7, pero habría pensado que el registro se habría realizado en una ubicación estándar que no cambiaría entre las versiones de Android.

Respuestas (2)

¿Alguien tiene alguna sugerencia sobre cómo puedo ver el texto completo de los errores que ocurren al intentar sincronizar mis carpetas K9?

Parece que no hay forma de ver estos mensajes de registro en el dispositivo sin acceso de root , pero si tiene acceso de root, hay un par de opciones, ya sea otorgar los permisos requeridos a aLogcat o considerar usar un truco horrible TM para ver ellos directamente.

Vea los archivos de registro en su PC o estación de trabajo a través deadb

Si puede conectar su dispositivo Android a una PC o estación de trabajo, puede acceder a los registros a través del adbcomando.

Para hacer esto en Windows, primero deberá instalar el SDK de Android (que requerirá el SDK de Java SE ) y agregar android-sdk\toolsy android-sdk\platform-toolsa la ruta del sistema . Luego habilite la depuración USB en su Nexus 7, conéctelo a través de USB e instale la interfaz ADB compuesta de Android desde android-sdk\extras\google\usb_driver(tuve que obligar a Windows XP a buscar aquí, no encontraría los controladores por sí solo).

Para obtener detalles sobre cómo comenzar adba funcionar sin la instalación completa del SDK de Android, o en máquinas Mac o Linux, consulte la excelente respuesta de Izzy a ¿Existe una instalación mínima de ADB?

Luego puede abrir un shell (es decir, una cmdventana) y ejecutar el comando:

adb logcat k9:V *:S AndroidRuntime:E
  • He confirmado que esto funciona en mi Nexus 7 no rooteado.

Otorgar permisos a aLogcat

Si tiene acceso de root , podría considerar otorgar el READ_LOGSpermiso a aLogcat , como se sugiere en esta publicación , ¿aLogcat/CatLog/Lumberjack no funciona? Haz esto... en el foro xda-developers :

pm grant <pkg> android.permission.READ_LOGS

Para otorgar este permiso a alogcato alogcat.donate, usaría uno de los siguientes comandos, dependiendo de si está ejecutando la versión de donación o no:

pm grant org.jtb.alogcat.donate android.permission.READ_LOGS
pm grant org.jtb.alogcat android.permission.READ_LOGS

De acuerdo con una publicación sobre desarrolladores de Android y el ticket , la concesión de permisos sobrevive al reinicio y la actualización, pero no a la desinstalación/reinstalación.

Lamentablemente, dado que esto requiere acceso de root, ya sea que lo ejecute en el dispositivo o en mi PC (con el prefijo adb shell), solo obtengo el error:

Neither user 12345 nor current process has android.permission.GRANT_REVOKE_PERMISSION
  • No puedo confirmar que esto funcione, ya que mi Nexus 7 no ha sido rooteado.

Considere usar un truco horrible TM

Si tiene acceso de root , podría considerar crear logcat setuid root y ejecutar logcat desde el shell del dispositivo, como se sugiere en esta respuesta a mi ¿Cómo puedo acceder a los archivos de registro de Android en mi Nexus 7 sin acceso de root? pregunta:

chmod 04755 /system/bin/logcat
logcat k9:V *:S AndroidRuntime:E
  • Nuevamente, no puedo confirmar que esto funcione y probablemente solo lo usaría como último recurso , dadas las implicaciones de seguridad.

¿Por qué no aparecen mensajes de registro de K9 en el visor de registros de aLogcat ?

¿Podría haber cambiado algo en Jelly Bean que hizo que el registro de K9 dejara de funcionar?

Dado que parece que aLogcat muestra muy pocos mensajes en general, ¿ha cambiado algo en Jelly Bean que podría significar que ya no puede acceder a todos los mensajes?

Esto parece ser un cambio en Jelly Bean que afecta a todas las aplicaciones que pueden intentar leer los archivos de registro.

Aparentemente , el permiso READ_LOGS no se otorga a aplicaciones de terceros en Jelly Bean . Dado que este enlace parece ser poco fiable:

Hoy probé mi aplicación en el emulador más nuevo (api 16) antes de publicarlo en Google Play. Resultó que Android ahora se niega a otorgar este permiso a aplicaciones de terceros. Esto es extraño porque revisé todos los cambios documentados de Jelly Bean y no pude encontrar nada que mencionara el permiso READ_LOGS.

y después

El nivel de protección para READ_LOGS ahora es "firma|sistema|desarrollo". La nueva sintaxis de canalización para el nivel de protección tampoco está documentada (consulte http://code.google.com/p/android/issues/detail?id=34785 ).

Mi sospecha es que aLogcat solo ve mensajes generados por sí mismo y es vm.

Para obtener más información, consulte las respuestas de Flujo a mi pregunta . ¿Qué tan activo debo esperar que esté mi archivo de registro del sistema Jelly Bean?

IIRC adb logcataún puede obtener el registro completo de Android en Jelly Bean.
No requiere root, pero debe habilitar adb en su dispositivo (generalmente en las opciones de desarrollador).
@Flow: ahora confirmé que puedo ver el registro en mi PC adb logcatdesde allí y actualicé mi respuesta en consecuencia. Todavía es frustrante que no puedo encontrar ninguna forma de acceder a los registros sin acceso de root desde el propio dispositivo.
El punto central en el cambio de registro de JB es que un usuario no root no puede acceder al registro completo del sistema.
@Flow: sí, y el objetivo de los mensajes de registro es que puede usarlos para averiguar qué está pasando. JB hace que una aplicación como aLogcat sea bastante inútil, ya que ahora solo puede acceder a los mensajes de registro que ha creado él mismo.
Creé una utilidad simple para acceder a los archivos de registro desde una PC: gist.github.com/hrj/5983971
Por cierto: no requiere una PC con Windows para usar ADB. También funciona bien en una Mac, y lo uso sin problemas en mi máquina Linux. Tampoco se necesita una instalación completa de SDK con todas sus dependencias (ver: ¿Hay una instalación mínima de ADB? ). Aparte de eso: excelente y completa respuesta :)
Gracias @Izzy, actualicé mi respuesta para hacer referencia a su respuesta y hacer que esa sección sea más genérica.
¡Gracias, buen trabajo! Un detalle más: mi respuesta vinculada también se aplica a Windows. No se necesita el SDK completo solo para que ADB funcione :)
Es por eso que coloqué el prefijo Para obtener detalles sobre cómo poner en funcionamiento adb sin la instalación completa del SDK de Android . Prefiero las respuestas independientes, por lo que no quería eliminar mi procedimiento, pero sí quería resaltar el suyo como alternativa.
¡Gracias! adb logcat k9:V *:S AndroidRuntime:E¡Me mostró el stacktrace del accidente matutino en la noche del día siguiente! ¡Log todavía estaba allí!

He visto este comportamiento en K9 cuando mi servidor de correo actualizó sus certificados SSL. La solución fue mantener presionada la cuenta, seleccionar Account settings -> Fetching mail -> Incoming servery simplemente Nextpasar las páginas para confirmar su configuración hasta que aparezca la ventana emergente sobre el certificado (es posible que no aparezca si todo está bien con el certificado, el mío tenía un vhost incorrecto). Confirme el certificado y simplemente realice el resto de la configuración y su cuenta debería comenzar a funcionar.

@MarkBooth Quizás debería haber preguntado eso, generalmente preferimos preguntas que no presuponen una solución.
@MatthewRead Debo estar de acuerdo con Mark aquí: los 4 elementos en su resumen indican explícitamente que quiere ayuda con el problema de registro, y tampoco veo el "problema XY" aquí (solución supuesta). K9 es claramente solo el ejemplo, pero tal vez el título de la pregunta debería ajustarse para subrayarlo: "Usar logcat para determinar la causa de los problemas" coincidiría (y enfocaría) mejor;)
@MarkBooth Yepp, tnx, mucho más claro ahora. ¡También tnx por la respuesta detallada! Por favor, manténganos informados sobre su progreso.
¿Debería eliminar mi respuesta, ya que está completamente fuera de tema después de las ediciones y es propenso a ser rechazado?
Depende de ti onik. Como dije originalmente, agradezco que se haya tomado el tiempo para publicar una respuesta, pero ahora que actualicé la pregunta, su respuesta parece aún más fuera de lugar. Supongo que siempre puedes esperar y ver si se vota por debajo de -3 para que puedas recoger tu insignia de presión de grupo. *8')
Problemas para acceder a los registros de mensajes en Jelly Bean con aLogcat
RespuestasAquíPolítica de privacidad1y, 0v