Cómo leer la salida “adb shell dumpsys alarm”

Estoy luchando por configurar una alarma correctamente y entender el mecanismo de cancelación y reprogtwigción de alarmas.

He encontrado que hay un comando adb para recuperar todas las alarmas progtwigdas en el dispositivo, pero no he encontrado una documentación que explique el formato de la salida.

Entiendo, que estoy pidiendo muchas explicaciones aquí, así que si alguien lanza un enlace con una explicación detallada sobre “adb shell dumpsys alarm”, realmente lo agradeceré.

Entonces, aquí están las preguntas:

  1. Lotes de alarma pendientes: 23

    a. ¿Hay ’23’ una cantidad de alarmas progtwigdas actualmente activas?

  2. Lote {4293d3a8 num = 1 inicio = 1369361 final = 1407261}:
    RTC # 0: alarma {4293d358 tipo 1 com.android.chrome}
    tipo = 1 whenElapsed = 1369361 cuando = + 19s304ms ventana = -1 repeatInterval = 0 count = 0
    operation = PendingIntent {429e4500: PendingIntentRecord {429dbbc8 com.android.chrome broadcastIntent}}

    a. ¿Qué es ‘num = 1’, ‘start = 1369361’ y ‘end = 1407261’?
    segundo. ‘RTC’ significa alarma RTC, supongo.
    do. ¿Qué significa ‘# 0’?
    re. ¿Qué significa ‘tipo = 1’?
    mi. ¿’Cuando = + 19s304ms’ significa que la alarma se disparará en 19 segundos?
    F. ¿Qué significa ‘ventana = -1’?
    gramo. ¿’RepeatInterval = 0′ significa que esta es una alarma no repetitiva?
    h. ¿’Count = 0′ significa que esta alarma no fue pospuesta, debido al estado de suspensión del teléfono?
    yo. ‘operation = PendingIntent {…}’ significa la intención pendiente, que será activada por la alarma, supongo.

  3. Recuento de transmisión: 0

    a. ¿Que es esto?

  4. Alarmas principales:

    a. ¿Que es esto?

  5. + 47s271ms en ejecución, 0 activaciones, 2 alarmas: com.nombredeusuario.weatherinfo
    act = com.username.receivers.CyclicWeatherUpdater.WEATHER_UPDATE_ACTION
    cmp = {com.username.weatherinfo / com.username.receivers.CyclicWeatherUpdater}

    a. ¿’+ 47s271ms’ significa que esta alarma se disparará en 47 segundos?
    segundo. ¿Qué es ‘0 wakeups’ – la alarma nunca se activó?
    do. ¿Qué es ‘2 alarmas’?
    re. ¿Está ‘com.username.weatherinfo’ por el nombre del paquete, que se asignó al bash pendiente en el campo de contexto?
    mi. ¿’Acto’ es la acción que se envió con intención?
    F. ¿Qué es ‘cmp’? Veo, que está compuesto por el nombre del paquete y el nombre de clase, pero ¿de dónde se toman? ¿Del constructor de intención? gramo. ¿Por qué parte de las alarmas solo tienen ‘actuar’ o solo ‘cmp’? He supuesto que las alarmas sin campos ‘cmp’ son para intenciones de emisión implícitas. Sin embargo, ¿por qué hay alarmas sin campo de “acción”?

  6. Estadísticas de alarma:

    a. ¿Que es esto?

Me doy cuenta de que este hilo es antiguo, pero las respuestas no son fáciles de encontrar y podrían ser útiles. Pasé un buen rato averiguando qué significan estos mensajes.

Q1: lotes

 Pending alarm batches: 23 

Las alarmas están organizadas en lotes. Como se describe en la documentación :

A partir de API 19, el tiempo de activación pasado a este método se trata como inexacto: la alarma no se entregará antes de este momento, pero puede diferirse y entregarse más tarde. El sistema operativo utilizará esta política para agrupar alarmas juntas en todo el sistema, minimizando la cantidad de veces que el dispositivo debe “activarse” y minimizar el uso de la batería. En general, las alarmas progtwigdas en un futuro próximo no se aplazarán mientras haya alarmas progtwigdas en el futuro.

Puede haber más de una alarma por lote. En este caso, hay 23 lotes de alarmas, lo que significa que probablemente haya muchas más de 23 alarmas progtwigdas. En la salida de dumpsys alarm , la línea que describe cada lote se ve así:

 Batch{4293d3a8 num=1 start=1369361 end=1407261}: 

En el cual:

  • 4293d3a8 es una identificación interna asociada con el lote.
  • num=1 es el número de alarmas en este lote. En este caso, solo hay una alarma en el lote.
  • los números de start y end representan la cantidad de milisegundos que han transcurrido desde que se reinició por última vez el sistema como se describe en esta publicación , y representan aproximadamente el intervalo de tiempo en el que se deben activar las alarmas en el lote.

Q2: Alarmas

Cada alarma está descrita por tres líneas que se ven así:

 RTC #0: Alarm{4293d358 type 1 com.android.chrome} type=1 whenElapsed=1369361 when=+19s304ms window=-1 repeatInterval=0 count=0 operation=PendingIntent{429e4500: PendingIntentRecord{429dbbc8 com.android.chrome broadcastIntent}} 

En el cual:

  • La primera parte, que es una de RTC_WAKEUP , RTC , ELAPSED_WAKEUP o ELAPSED , representa el type de alarma y corresponde a un valor entero de 0-3, respectivamente
  • #0 es el número de la alarma dentro del lote, donde los números van de 0 a n-1 donde n es el número de alarmas en el lote. Si su alarma se combina con otras, la más lejana en el futuro “cuando =” define el momento en que se activarán todas las alarmas en el lote.
  • 4293d358 es un número de identificación interna asociado con la alarma
  • com.android.chrome es el nombre del paquete de la clase que configuró la alarma
  • type=1 , el tipo de alarma, ver primera viñeta arriba
  • whenElapsed=1369361 refiere a la cantidad de milisegundos desde que se inició el sistema en el que se activará esta alarma (aproximadamente)
  • when=+19s304ms significa que la alarma se disparará en 19 segundos, 304 milisegundos desde el momento en que se dumpsys alarm . Del mismo modo, un valor como +2d13h29m03s882ms refiere a un tiempo relativo de 2 días, 13 horas, 29 minutos … en el futuro
  • window= refiere a una de las dos constantes internas que tienen que ver con el método en el que se dispara la alarma. AlarmManager.WINDOW_EXACT=0 y se establece cuando la alarma está progtwigda con setExact() o setAlarmClock() . AlarmManager.WINDOW_HEURISTIC=-1 y se configura cuando la alarma está progtwigda con setInexactRepeating() . De lo contrario, el valor está determinado por la versión API. Para API <19 (KitKat), se usa WINDOW_EXACT y para API> = 19, se usa WINDOW_HEURISTIC . (Tuve que profundizar en el código fuente AlarmManager.java para resolver esto.)
  • repeatInterval=900000 es la frecuencia con la que se repite la alarma, por ejemplo, cada 900000ms o 15 minutos. Un valor de 0 significa que la alarma no se repite.
  • count= refiere a la cantidad de veces que una alarma debería haberse activado, pero no fue por alguna razón. 0 es un buen número aquí. > 0 significa que la alarma fue omitida por alguna razón.
  • operation=PendingIntent{...} es una referencia al PendingIntent que se activa por la alarma. Dependiendo de si el PendingIntent fue instanciado usando getService , getBroadcast , getActivity o getActivities , la alarma iniciará un servicio, enviará una transmisión o iniciará una o más actividades.

Q3: recuento de ref de transmisión

Para averiguar sobre este y otros elementos de salida después de esto, tuve que profundizar en el código fuente de AlarmManagerService.java .

Para que algunas alarmas funcionen, el dispositivo debe ser activado y no debe volverse a dormir hasta que se hayan enviado todas las transmisiones necesarias. La variable interna mBroadcastRefCount se inicializa en 0 y se incrementa a medida que las transmisiones que se envían se ponen en cola. A medida que se envía cada transmisión, se reduce y cuando vuelve a 0, se lanza wakeLock y está bien que el dispositivo vuelva a dormirse.

Broadcast Ref Count: 0 simplemente significa que en el momento en que se dumpsys alarm , no estaba en el medio de enviar transmisiones.

Q4: Alarmas superiores

Estas son las diez principales alarmas clasificadas en orden descendente por el tiempo total agregado que se ha ejecutado el código de alarma. Esto se puede utilizar para encontrar alarmas que consumen la mayor cantidad de recursos del sistema, por ejemplo, para encontrar procesos que pueden tener fallas para agotar la vida útil de la batería.

Q5: Estadísticas de alarma

Esta sección muestra las estadísticas de todas las alarmas que se han ejecutado desde que se reinició el sistema por última vez. Aquí es donde puede ver si las alarmas que configuró en el pasado se activaron, si despertaron el teléfono, etc. El formato de estas entradas se trata a continuación.

P6: entradas de estadísticas de alarma

Las entradas de estadísticas de alarma se ven así:

 com.example.someapp +1s857ms running, 0 wakeups: +1s817ms 0 wakes 83 alarms: cmp={com.example.someapp/com.example.someapp.someservice} +40ms 0 wakes 1 alarms: cmp={com.example.someapp/com.example.someapp.someotherservice} 

donde en la primera linea:

  • com.example.someapp es el nombre del paquete del proceso que activó la alarma
  • +1s857ms running es el tiempo total del sistema consumido por los procesos
  • 0 wakeups es la cantidad de veces que el dispositivo fue despertado por una de estas alarmas

y luego cada línea después de eso se refiere a una de las alarmas que se estableció, con:

  • +1s817ms es el tiempo total del sistema consumido
  • 0 wakes es la cantidad de veces que el dispositivo tuvo que ser despertado
  • 83 alarms es la cantidad de veces que se activó la alarma; esto solo será> 1 para repetir alarmas
  • cmp={...} el servicio que se inició cuando se activó la alarma

Alternativamente, si la alarma activó una transmisión, la entrada podría verse así:

 android +4m51s566ms running, 281 wakeups: +2m46s583ms 0 wakes 1224 alarms: act=android.intent.action.TIME_TICK +1m25s624ms 89 wakes 89 alarms: act=android.content.syncmanager.SYNC_ALARM +52s898ms 0 wakes 41 alarms: act=com.android.server.action.NETWORK_STATS_POLL ... 

con:

  • act=... siendo el nombre de la intención que se transmitió

Es posible que una alarma tenga una entrada cmp={...} y una act=... , lo que significa que la alarma emitió un bash e inició un servicio.

Resumen

Depurar las alarmas de Android usando la salida de la adb shell dumpsys alarm de adb shell dumpsys alarm puede ser complicado, y no hay una ubicación central donde los mensajes de dumpsys estén completamente explicados. No siempre es evidente cómo se agrupan las alarmas y, a veces, es difícil hacer que un servicio o actividad se active exactamente cuando se desee. Esperemos que esta sea una referencia útil para las personas que intentan depurar sus alarmas.

Como alguien que también luchó con las alarmas, aquí hay dos consejos:

Depuración de salida de shell:

  • ver tiempos negativos o grandes (por ejemplo, -2hr57m20s311ms, 14d5hr23m07s500ms), fue porque confundí el tipo de reloj (por ejemplo, RTC con ELAPSED). Esto está claro en la documentación, ” RTC_WAKEUP: Alarm time in System.currentTimeMillis()https://developer.android.com/reference/android/app/AlarmManager.html#RTC_WAKEUP

  • cancelando alarmas en tiempo real (después de crearlas). Utilice la cancelación, que si programó un bash pendiente necesita ambas: alarmManager.cancel(pendingIntent) y pendingIntent.cancel()

Aunque la respuesta de morphatic es todo lo que necesita saber, he creado un proyecto de código abierto para una GUI que muestra la misma información de una manera visual. Creo que podría ser útil para otros, ya que fue para mí en primer lugar.

https://github.com/Dottorhouse/DumpsysAlarm