Comment lire la sortie «Alarme adb shell dumpsys»

Je me rends compte que ce fil est vieux, mais les réponses ne sont pas faciles à trouver et pourraient être utiles. J’ai passé un bon moment à définir ce que signifient ces messages.

Q1: Lots

 Pending alarm batches: 23 

Les alarmes sont organisées en lots. Comme décrit dans la documentation :

À partir de l’API 19, le temps de déclenchement transmis à cette méthode est considéré comme inexact: l’alarme ne sera pas livrée avant cette heure, mais pourra être différée et livrée plus tard. Le système d’exploitation utilisera cette stratégie pour “ regrouper ” les alarmes ensemble sur l’ensemble du système, en minimisant le nombre de fois que l’appareil doit “se réveiller” et minimiser l’utilisation de la batterie. En général, les alarmes programmées dans un avenir proche ne seront pas rescopes aussi longtemps que les alarmes programmées dans le futur.

Il peut y avoir plus d’une alarme par lot. Dans ce cas, il y a 23 lots d’alarmes, ce qui signifie qu’il y a probablement plus de 23 alarmes programmées. Dans la sortie d’ dumpsys alarm , la ligne décrivant chaque lot ressemble à:

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

Dans lequel:

• 4293d3a8 est un identifiant interne associé au lot.
• num=1 est le nombre d’alarmes dans ce lot. Dans ce cas, il n’y a qu’une seule alarme dans le lot.
• les nombres de start et de end représentent le nombre de millisecondes écastings depuis le dernier redémarrage du système, comme décrit dans cet article , et représentent en gros la fenêtre dans laquelle les alarmes du lot doivent être déclenchées.

Q2: Alarmes

Chaque alarme est décrite par trois lignes qui ressemblent à:

 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}} 

Dans lequel:

• La première partie, qui est l’une des RTC_WAKEUP , RTC , ELAPSED_WAKEUP ou ELAPSED , représente le type d’alarme et correspond respectivement à un nombre entier ELAPSED 0 et 3.
• #0 est le numéro de l’alarme dans le lot, où les nombres vont de 0 à n-1 où n est le nombre d’alarmes dans le lot. Si votre alarme est mise en lots avec d’autres, la plus éloignée à l’avenir “when =” définit l’heure à laquelle toutes les alarmes du lot seront déclenchées.
• 4293d358 est un numéro d’identification interne associé à l’alarme
• com.android.chrome est le nom du paquet de la classe qui a défini l’alarme
• type=1 , le type d’alarme, voir la première puce ci-dessus
• whenElapsed=1369361 fait référence au nombre de millisecondes whenElapsed=1369361 depuis le démarrage du système auquel cette alarme sera déclenchée (approximativement)
• when=+19s304ms signifie que l’alarme sera déclenchée en 19 secondes, 304 millisecondes à partir du moment où l’ dumpsys alarm été appelée. De même, une valeur comme +2d13h29m03s882ms fait référence à un temps relatif 2 jours, 13 heures, 29 minutes … dans le futur
• window= fait référence à l’une des deux constantes internes ayant trait à la méthode par laquelle l’alarme est mise en lots. AlarmManager.WINDOW_EXACT=0 et est défini lorsque l’alarme est planifiée avec setExact() ou setAlarmClock() . AlarmManager.WINDOW_HEURISTIC=-1 et est défini lorsque l’alarme est programmée avec setInexactRepeating() . Sinon, la valeur est déterminée par la version de l’API. Pour API <19 (KitKat), WINDOW_EXACT est utilisé et pour API> = 19, WINDOW_HEURISTIC est utilisé. (J’ai dû creuser dans le code source de AlarmManager.java pour comprendre cela.)
• repeatInterval=900000 est la fréquence à laquelle l’alarme se répète, par exemple toutes les 900 000 ms ou 15 minutes. Une valeur de 0 signifie que l’alarme ne se répète pas.
• count= indique le nombre de fois où une alarme aurait dû être déclenchée, mais ce n’était pas pour une raison quelconque. 0 est un bon chiffre ici. > 0 signifie que l’alarme a été ignorée pour une raison quelconque.
• operation=PendingIntent{...} est une référence à PendingIntent qui est déclenché par l’alarme. Selon que l’ PendingIntent été instanciée à l’aide de getService , getBroadcast , getActivity ou getActivities , l’alarme démarre un service, envoie une diffusion ou démarre une ou plusieurs activités.

Q3: nombre de références de diffusion

Pour en savoir plus et d’autres éléments de sortie après cela, j’ai dû creuser dans le code source AlarmManagerService.java .

Pour que certaines alarmes fonctionnent, l’appareil doit être réveillé et ne doit pas se rendormir tant que toutes les diffusions nécessaires n’ont pas été envoyées. La variable interne mBroadcastRefCount est initialisée à 0 et est incrémentée au fur et à mesure de l’envoi des diffusions. Au fur et à mesure de l’envoi de chaque diffusion, celle-ci est décrémentée et lorsqu’elle revient à 0, le wakeLock est libéré et il est possible que l’appareil revienne en mode veille.

Broadcast Ref Count: 0 signifie simplement qu’au moment où l’ dumpsys alarm était lancée, elle n’était pas en train d’envoyer des diffusions.

Q4: Top Alarms

Il s’agit des dix premières alarmes classées par ordre décroissant de la durée totale cumulée du code d’alarme. Cela peut être utilisé pour trouver des alarmes qui consumnt la plus grande quantité de ressources système, par exemple pour trouver des processus pouvant être en cause pour drainer la durée de vie de la batterie.

Q5: Statistiques d’alarme

Cette section affiche les statistiques pour toutes les alarmes qui ont été exécutées depuis le dernier redémarrage du système. C’est là que vous pouvez voir si les alarmes que vous avez définies dans le passé ont été déclenchées, si elles ont réveillé le téléphone, etc. Le format de ces entrées est traité ci-après.

Q6: Entrées statistiques

Les entrées de statistiques d’alarme ressemblent à:

 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} 

où dans la première ligne:

• com.example.someapp est le nom du processus qui a déclenché l’alarme
• +1s857ms running est la durée totale du système consommée par les processus
• 0 wakeups est le nombre de fois où l’appareil a été réveillé par l’une de ces alarmes.

puis chaque ligne qui suit fait référence à l’une des alarmes définies, avec:

• +1s817ms est la durée totale du système consommée
• 0 wakes est le nombre de fois où l’appareil a dû être réveillé
• 83 alarms est le nombre de fois où l’alarme a été déclenchée; ce ne sera que> 1 pour les alarmes répétitives
• cmp={...} le service qui a été lancé au déclenchement de l’alarme

Sinon, si l’alarme a déclenché une diffusion, l’entrée pourrait ressembler à:

 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 ... 

avec:

• act=... étant le nom de l’intention diffusée

Il est possible qu’une alarme ait à la fois une entrée cmp={...} et une act=... , ce qui signifie que l’alarme diffuse une intention et lance un service.

Résumé

Le débogage des alarmes Android à l’aide de la sortie de l’ adb shell dumpsys alarm peut être délicat, et il n’y a pas d’emplacement central où les messages dumpsys sont entièrement expliqués. Il n’est pas toujours évident de voir comment les alarmes sont regroupées, et il est parfois difficile de déclencher un service ou une activité au moment voulu. J’espère que cela sera une référence utile pour les personnes essayant de déboguer leurs alarmes.

En tant que personne qui a également lutté avec les alarmes, voici deux conseils:

Débogage de la sortie du shell:

• voir des temps négatifs ou énormes (par exemple, -2hr57m20s311ms, 14d5hr23m07s500ms), c’est parce que j’ai confondu le type d’horloge (par exemple, RTC avec ELAPSED). Ceci est clair dans la documentation, ” RTC_WAKEUP: Alarm time in System.currentTimeMillis() ” https://developer.android.com/reference/android/app/AlarmManager.html#RTC_WAKEUP

• annuler les alarmes en temps réel (après les avoir créées). Utilisez l’annulation qui, si vous avez planifié une intention en attente, nécessite à la fois: alarmManager.cancel(pendingIntent) et pendingIntent.cancel()

Même si la réponse de morphatic est tout ce que vous devez savoir, j’ai créé un projet open source pour une interface graphique afin d’afficher les mêmes informations de manière visuelle. Je pense que cela pourrait être utile pour les autres, car cela a été pour moi en premier lieu.

https://github.com/Dottorhouse/DumpsysAlarm