Lectura de 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 recibir informes de errores y compartirlos por correo electrónico, Drive, etc.

Los informes de errores de Android contienen datos de 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 para el comando y la salida grep y/o la salida dumpsys .

Logcat

El registro de logcat es un volcado basado en cadenas de toda la información de 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. Cada línea generalmente comienza con la timestamp UID PID TID log-level , aunque es posible que el UID no aparezca en las 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 logcat pero también un poco más difícil de leer. Al ver los 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: informacion
  • W: advertencia
  • mi: 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 ayudarlo a identificar qué está causando los errores de aplicación que no responde (ANR) y los eventos de interbloqueo.

Identificación de aplicaciones que no responden

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

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

Encontrar rastros de pila

A menudo puede 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, luego verifique el hilo principal del proceso. Tenga en cuenta:

  • El subproceso principal solo le dice qué estaba haciendo el subproceso en el momento de la ANR, lo que puede corresponder o no a la verdadera causa de la ANR. (La pila en el informe de error puede ser inocente; algo más puede haber estado atascado durante mucho tiempo, pero no lo suficiente como para ANR, antes de despegarse).
  • Puede existir 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 interbloqueos

Los interbloqueos a menudo aparecen primero como ANR porque los subprocesos se atascan. Si el interbloqueo 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 de tiempo de ejecución , el servidor del sistema muere y se reinicia; el usuario ve que el dispositivo vuelve a la animación de arranque.
  • En un reinicio , el núcleo se bloqueó; el usuario ve que el dispositivo vuelve al logotipo de inicio de Google.

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

Ocupaciones

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 ubicar la actividad que estaba enfocada durante un choque. Las actividades (a través de ActivityManager) ejecutan procesos, por lo que ubicar todas las paradas e inicios de procesos para una actividad determinada también puede ayudar a solucionar problemas.

Visualización de actividades enfocadas

Para ver un historial de actividades enfocadas, busque am_focused_activity .

Comienza el proceso de visualización

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

¿El dispositivo está golpeando?

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

Memoria

Debido a que los dispositivos Android a menudo tienen una memoria física restringida, la administració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.

Identificación de poca memoria

La poca memoria puede hacer que el sistema se acelere, ya que elimina algunos procesos para liberar memoria, pero continúa iniciando otros procesos. Para ver pruebas que corroboren la falta de memoria, busque concentraciones de 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 volver se eliminó). Si el iniciador se eliminó, se reinicia cuando el usuario toca el botón de inicio y los registros muestran que el iniciador vuelve a cargar su contenido.

Visualización de indicadores históricos

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

Visualización de indicadores de paliza

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

Los registros ANR pueden proporcionar una instantánea de 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 de Java en ejecución (para obtener detalles, consulte Visualización de las asignaciones generales de memoria ). Tenga en cuenta que la instantánea proporciona solo 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 oa otra aplicación. Los receptores de transmisiones 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 transmisiones no enviadas, así como un dumpsys de todos los receptores que escuchan una transmisión específica.

Visualización de transmisiones históricas

Las transmisiones históricas son aquellas que ya se han enviado, enumeradas en orden cronológico inverso.

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 detalle 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 de 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. El 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 gran número en la cola significa que el sistema no puede enviar las transmisiones lo suficientemente rápido para mantenerse al día.

Visualización de los oyentes de la 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 monitor 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 fondo

La compilación puede ser 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 de la tienda Google Play ( finsky ) y la installd aparecen antes que los mensajes de dex2oat .

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

Narrativa

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

Sincronización de líneas de tiempo

Un informe de errores 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 la 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 ) usan una base de tiempo diferente, etiquetando los elementos de registro con segundos desde que se completa el cargador 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 los registros del núcleo pueden no incluir el tiempo mientras está suspendido, debe registrar el registro por partes entre la entrada de suspensión y los mensajes de salida. Además, los registros del kernel usan la zona horaria UTC y deben ajustarse a la zona horaria del usuario.

Identificar el tiempo de reporte de errores

Para determinar cuándo se tomó un informe de error, primero verifique el registro del sistema (Logcat) para el estado de 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 errores, la mayor parte de la actividad no es muy útil ya que el acto de tomar el informe de errores carga el sistema sustancialmente.

Energía

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 para el bloqueo del teclado.

Los informes de errores también contienen estadísticas sobre wake locks, 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 wake locks, consulte PowerManager.WakeLock y Keep the CPU on ).

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, use Battery Historian , una herramienta de código abierto de Google para analizar los consumidores de batería mediante archivos de informe de errores de Android.

Paquetes

La sección del 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, incluida la hora 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 .

Determinación del tiempo de ejecución del proceso

La sección procstats contiene estadísticas completas sobre cuánto tiempo se han estado ejecutando 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 en varias prioridades y su RAM uso formateado como min-average-max PSS/min-average-max USS.

¿Por qué se está ejecutando un proceso?

La sección de 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 puede ser actualizado dinámicamente por ActivityManager). 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

Use los siguientes pasos para identificar las aplicaciones que realizan escaneos excesivos de Bluetooth Low Energy (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 con el 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 de inicio. Para obtener más información, consulte Análisis de baja energía (LE) y Bluetooth .