Leer informes de errores

Los errores son una realidad en cualquier tipo de desarrollo y los informes de errores son fundamentales para identificar y resolver problemas. Todas las versiones de Android admiten la captura de informes de errores con Android Debug Bridge (adb) ; Las versiones de Android 4.2 y superiores admiten una opción de desarrollador para generar informes de errores y compartirlos por correo electrónico, Drive, etc.

Los informes de errores de Android contienen datos dumpsys , dumpstate y logcat en formato de texto (.txt), lo que le permite buscar fácilmente contenido específico. Las siguientes secciones detallan los componentes del informe de errores, describen problemas comunes y brindan consejos útiles y comandos grep para encontrar registros asociados con esos errores. La mayoría de las secciones también incluyen ejemplos de comando y salida grep y/o salida dumpsys .

logcat

El registro logcat es un volcado basado en cadenas de toda la información logcat . La parte del sistema está reservada para el marco y tiene un historial más largo que el principal , que contiene todo lo demás. Por lo general, cada línea comienza con timestamp UID PID TID log-level , aunque es posible que el UID no aparezca en versiones anteriores de Android.

Ver el registro de eventos

Este registro contiene representaciones de cadenas de mensajes de registro con formato binario. Es menos ruidoso que el registro logcat pero también un poco más difícil de leer. Al ver registros de eventos, puede buscar en esta sección un ID de proceso específico (PID) para ver qué ha estado haciendo un proceso. El formato básico es: timestamp PID TID log-level log-tag tag-values .

Los niveles de registro incluyen lo siguiente:

  • V: detallado
  • D: depurar
  • yo: información
  • W: advertencia
  • ES: error

Para otras etiquetas de registro de eventos útiles, consulte /services/core/java/com/android/server/EventLogTags.logtags .

ANR y puntos muertos

Los informes de errores pueden ayudarle a identificar la causa de los errores de aplicación que no responde (ANR) y los eventos de bloqueo.

Identificar aplicaciones que no responden

Cuando una aplicación no responde dentro de un tiempo determinado, generalmente debido a un hilo principal bloqueado u ocupado, el sistema finaliza el proceso y vuelca la pila en /data/anr . Para descubrir al culpable detrás de un ANR, busque am_anr en el registro de eventos binarios.

También puede buscar ANR in el registro logcat , que contiene más información sobre qué estaba usando la CPU en el momento del ANR.

Encuentra seguimientos de pila

A menudo puedes encontrar seguimientos de pila que corresponden a un ANR. Asegúrese de que la marca de tiempo y el PID en los seguimientos de la VM coincidan con el ANR que está investigando y luego verifique el hilo principal del proceso. Tenga en cuenta:

  • El hilo principal le dice solo lo que estaba haciendo el hilo en el momento del ANR, lo que puede corresponder o no a la verdadera causa del ANR. (La pila en el informe de error puede ser inocente; es posible que algo más haya estado atascado durante mucho tiempo, pero no lo suficiente como para ANR, antes de despegarse).
  • Es posible que exista más de un conjunto de seguimientos de pila ( VM TRACES JUST NOW y VM TRACES AT LAST ANR ). Asegúrate de estar viendo la sección correcta.

encontrar puntos muertos

Los interbloqueos a menudo aparecen primero como ANR porque los subprocesos se atascan. Si el punto muerto llega al servidor del sistema, el perro guardián eventualmente lo eliminará, lo que generará una entrada en el registro similar a: WATCHDOG KILLING SYSTEM PROCESS . Desde la perspectiva del usuario, el dispositivo se reinicia, aunque técnicamente se trata de un reinicio en tiempo de ejecución en lugar de un reinicio real.

  • En un reinicio en tiempo de ejecución , el servidor del sistema muere y se reinicia; el usuario ve que el dispositivo regresa a la animación de inicio.
  • Al reiniciar , el kernel falló; el usuario ve que el dispositivo regresa al logotipo de inicio de Google.

Para encontrar interbloqueos, consulte las secciones de seguimiento de VM para ver un patrón de subproceso A esperando algo retenido por el subproceso B, que a su vez está esperando algo retenido por el subproceso A.

Actividades

Una Actividad es un componente de la aplicación que proporciona una pantalla con la que los usuarios interactúan para hacer algo como marcar un número, tomar una foto, enviar un correo electrónico, etc. Desde la perspectiva del informe de errores, una actividad es una cosa única y enfocada que un usuario puede hacer. , lo que hace que sea muy importante localizar la actividad que estuvo enfocada durante un accidente. Las actividades (a través de ActivityManager) ejecutan procesos, por lo que localizar todas las paradas e inicios de procesos para una actividad determinada también puede ayudar a solucionar problemas.

Ver actividades enfocadas

Para ver un historial de actividades enfocadas, busque am_focused_activity .

Ver proceso comienza

Para ver un historial de inicios de procesos, busque Start proc .

Determinar si el dispositivo está golpeando

Para determinar si el dispositivo está funcionando mal , verifique si hay un aumento anormal en la actividad alrededor am_proc_died y am_proc_start en un corto período de tiempo.

Memoria

Dado que los dispositivos Android suelen tener una memoria física limitada, la gestión de la memoria de acceso aleatorio (RAM) es fundamental. Los informes de errores contienen varios indicadores de poca memoria, así como un estado de volcado que proporciona una instantánea de la memoria.

Identificar poca memoria

La poca memoria puede hacer que el sistema funcione mal, ya que mata algunos procesos para liberar memoria pero continúa iniciando otros procesos. Para ver evidencia que corrobore la falta de memoria, verifique las concentraciones de las entradas am_proc_died y am_proc_start en el registro de eventos binarios.

La poca memoria también puede ralentizar el cambio de tareas y frustrar los intentos de devolución (porque la tarea a la que el usuario intentaba regresar fue eliminada). Si el iniciador se eliminó, se reinicia cuando el usuario toca el botón de inicio y los registros muestran que el iniciador recarga su contenido.

Ver indicadores históricos

La entrada am_low_memory en el registro de eventos binarios indica que el último proceso almacenado en caché ha finalizado. Después de esto, el sistema comienza a cerrar servicios.

Ver indicadores de goleada

Otros indicadores de destrucción del sistema (paginación, recuperación directa, etc.) incluyen ciclos de consumo kswapd , kworker y mmcqd . (Tenga en cuenta que el informe de error que se recopila puede influir en los indicadores de destrucción).

Los registros ANR pueden proporcionar una instantánea de la memoria similar.

Obtener una instantánea de la memoria

La instantánea de la memoria es un estado de volcado que enumera los procesos nativos y Java en ejecución (para obtener más detalles, consulte Visualización de las asignaciones generales de memoria ). Tenga en cuenta que la instantánea solo proporciona el estado en un momento específico; el sistema podría haber estado en mejor (o peor) forma antes de la instantánea.

Transmisiones

Las aplicaciones generan transmisiones para enviar eventos dentro de la aplicación actual o a otra aplicación. Los receptores de transmisión se suscriben a mensajes específicos (a través de filtros), lo que les permite escuchar y responder a una transmisión. Los informes de errores contienen información sobre transmisiones enviadas y no enviadas, así como también un resumen de todos los receptores que escuchan una transmisión específica.

Ver transmisiones históricas

Las emisiones históricas son aquellas que ya han sido enviadas, ordenadas cronológicamente de forma inversa.

La sección de resumen es una descripción general de las últimas 300 transmisiones en primer plano y las últimas 300 transmisiones en segundo plano.

La sección de detalles contiene información completa de las últimas 50 transmisiones en primer plano y las últimas 50 transmisiones en segundo plano, así como los receptores de cada transmisión. Receptores que tienen:

  • Las entradas BroadcastFilter se registran en tiempo de ejecución y se envían solo a los procesos que ya se están ejecutando.
  • Las entradas ResolveInfo se registran a través de entradas de manifiesto. ActivityManager inicia el proceso para cada ResolveInfo si aún no se está ejecutando.

Ver transmisiones activas

Las transmisiones activas son aquellas que aún no se han enviado. Un número grande en la cola significa que el sistema no puede enviar las transmisiones lo suficientemente rápido para mantenerse al día.

Ver oyentes de transmisión

Para ver una lista de receptores que escuchan una transmisión, consulte la tabla de resolución de receptores en las dumpsys activity broadcasts . El siguiente ejemplo muestra todos los receptores que escuchan USER_PRESENT .

Supervisar la contención

El registro de contención del monitor a veces puede indicar una contención real del monitor, pero la mayoría de las veces indica que el sistema está tan cargado que todo se ha ralentizado. Es posible que vea eventos de monitorización prolongados registrados por ART en el sistema o en el registro de eventos.

En el registro del sistema:

10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

En el registro de eventos:

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

Compilación de antecedentes

La compilación puede resultar costosa y cargar el dispositivo.

La compilación puede ocurrir en segundo plano cuando se descargan las actualizaciones de la tienda Google Play. En este caso, los mensajes de la aplicación Google Play Store ( finsky ) e installd aparecen antes que los mensajes dex2oat .

La compilación también puede ocurrir en segundo plano cuando una aplicación carga un archivo dex que aún no se ha compilado. En este caso, no verá el registro finsky o installd .

Narrativo

Establecer la narrativa de un problema (cómo empezó, qué sucedió, cómo reaccionó el sistema) requiere una línea de tiempo sólida de los eventos. Puede utilizar la información del informe de error para sincronizar líneas de tiempo en varios registros y determinar la marca de tiempo exacta del informe de error.

Sincronizar líneas de tiempo

Un informe de error refleja múltiples líneas de tiempo paralelas: registro del sistema, registro de eventos, registro del kernel y múltiples líneas de tiempo especializadas para transmisiones, estadísticas de batería, etc. Desafortunadamente, las líneas de tiempo a menudo se informan utilizando diferentes bases de tiempo.

Las marcas de tiempo del sistema y del registro de eventos están en la misma zona horaria que el usuario (al igual que la mayoría de las otras marcas de tiempo). Por ejemplo, cuando el usuario toca el botón de inicio, el registro del sistema informa:

10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

Para la misma acción, el registro de eventos informa:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

Los registros del kernel ( dmesg ) utilizan una base de tiempo diferente y etiquetan los elementos del registro con segundos desde que se completa el gestor de arranque. Para registrar esta escala de tiempo en otras escalas de tiempo, busque mensajes de suspensión de salida y suspensión de entrada :

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

Debido a que es posible que los registros del kernel no incluyan el tiempo mientras está en suspensión, debe registrar el registro por partes entre los mensajes de entrada y salida de suspensión. Además, los registros del kernel utilizan la zona horaria UTC y deben ajustarse a la zona horaria del usuario.

Identificar el tiempo de informe de errores

Para determinar cuándo se tomó un informe de error, primero verifique el registro del sistema (Logcat) para ver el dumpstate: begin :

10-03 17:19:54.322 19398 19398 I dumpstate: begin

A continuación, verifique las marcas de tiempo del registro del kernel ( dmesg ) para ver el mensaje Starting service 'bugreport' :

<5>[207064.285315] init: Starting service 'bugreport'...

Trabaje hacia atrás para correlacionar los dos eventos, teniendo en cuenta las advertencias mencionadas en Sincronización de líneas de tiempo . Si bien suceden muchas cosas después de que se inicia el informe de error, la mayor parte de la actividad no es muy útil ya que el acto de tomar el informe de error carga sustancialmente el sistema.

Fuerza

El registro de eventos contiene el estado de energía de la pantalla, donde 0 es la pantalla apagada, 1 es la pantalla encendida y 2 es el bloqueo del teclado realizado.

Los informes de errores también contienen estadísticas sobre bloqueos de activación, un mecanismo utilizado por los desarrolladores de aplicaciones para indicar que su aplicación necesita que el dispositivo permanezca encendido. (Para obtener detalles sobre los bloqueos de activación, consulte PowerManager.WakeLock y Mantenga la CPU encendida ).

Las estadísticas agregadas de duración del bloqueo de activación rastrean solo el tiempo que un bloqueo de activación es realmente responsable de mantener el dispositivo despierto y no incluyen el tiempo con la pantalla encendida. Además, si se mantienen varios bloqueos de activación simultáneamente, el tiempo de duración del bloqueo de activación se distribuye entre esos bloqueos de activación.

Para obtener más ayuda para visualizar el estado de la energía, utilice Battery Historian , una herramienta de código abierto de Google para analizar los consumidores de batería mediante archivos de informes de errores de Android.

Paquetes

La sección DUMP OF SERVICE package contiene versiones de la aplicación (y otra información útil).

Procesos

Los informes de errores contienen una gran cantidad de datos para los procesos, incluido el tiempo de inicio y finalización, la duración del tiempo de ejecución, los servicios asociados, la puntuación oom_adj , etc. Para obtener detalles sobre cómo Android administra los procesos, consulte Procesos y subprocesos .

Determinar el tiempo de ejecución del proceso

La sección procstats contiene estadísticas completas sobre cuánto tiempo han estado ejecutándose los procesos y los servicios asociados. Para obtener un resumen rápido y legible por humanos, busque AGGREGATED OVER para ver los datos de las últimas tres o 24 horas, luego busque Summary: para ver la lista de procesos, cuánto tiempo se han ejecutado esos procesos con diversas prioridades y su RAM. uso formateado como PSS mínimo-promedio-máximo/mínimo-promedio-máximo USS.

Razones por las que se está ejecutando un proceso

La sección dumpsys activity processes enumera todos los procesos actualmente en ejecución ordenados por puntuación oom_adj (Android indica la importancia del proceso al asignarle un valor oom_adj , que ActivityManager puede actualizar dinámicamente). El resultado es similar al de una instantánea de la memoria , pero incluye información adicional sobre la causa de la ejecución del proceso. En el siguiente ejemplo, las entradas en negrita indican que el proceso gms.persistent se está ejecutando con prioridad vis (visible) porque el proceso del sistema está vinculado a su NetworkLocationService .

Escaneos

Utilice los siguientes pasos para identificar aplicaciones que realizan escaneos excesivos de Bluetooth de baja energía (BLE):

  • Buscar mensajes de registro para BluetoothLeScanner :
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • Localice el PID en los mensajes de registro. En este ejemplo, "24840" y "24851" son PID (ID de proceso) y TID (ID de subproceso).
  • Localice la aplicación asociada al PID:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    En este ejemplo, el nombre del paquete es com.badapp .

  • Busque el nombre del paquete en Google Play para identificar la aplicación responsable: https://play.google.com/store/apps/details?id=com.badapp .

Nota : Para dispositivos que ejecutan Android 7.0, el sistema recopila datos para escaneos BLE y asocia estas actividades con la aplicación iniciadora. Para obtener más información, consulte Exploraciones de bajo consumo de energía (LE) y Bluetooth .