Mir ist klar, dass dieser Thread alt ist, aber die Antworten sind nicht leicht zu finden und könnten von Nutzen sein. Ich habe viel Zeit damit verbracht, herauszufinden, was diese Nachrichten bedeuten.
Q1: Chargen
Pending alarm batches: 23
Alarme sind in Stapeln organisiert. Wie in der Dokumentation beschrieben :
Ab API 19 wird die an diese Methode übergebene Auslösezeit als ungenau behandelt: Der Alarm wird nicht vor dieser Zeit übermittelt, kann jedoch verschoben und einige Zeit später übermittelt werden. Das Betriebssystem verwendet diese Richtlinie, um Alarme im gesamten System zu "stapeln", um die Häufigkeit zu minimieren, mit der das Gerät "aufwachen" muss, und um den Batterieverbrauch zu minimieren. Im Allgemeinen werden in naher Zukunft geplante Alarme nicht zurückgestellt, solange weit in der Zukunft geplante Alarme vorliegen.
Es kann mehr als einen Alarm pro Charge geben. In diesem Fall gibt es 23 Chargen von Alarmen, was bedeutet, dass wahrscheinlich viel mehr als 23 Alarme geplant sind. In der dumpsys alarm
Ausgabe sieht die Zeile, die jede Charge beschreibt, folgendermaßen aus:
Batch{4293d3a8 num=1 start=1369361 end=1407261}:
In welchem:
4293d3a8
ist eine interne ID, die dem Stapel zugeordnet ist.
num=1
ist die Anzahl der Alarme in dieser Charge. In diesem Fall gibt es nur einen Alarm im Stapel.
- die
start
und end
Zahlen repräsentieren die Anzahl der Millisekunden , die vergangen sind , seit dem System zuletzt als neu gestartet wurde beschrieben in diesem Beitrag , und auch grob repräsentiert das Zeitfenster , in dem die Alarme im Batch ausgelöst werden.
Q2: Alarme
Jeder Alarm wird durch drei Zeilen beschrieben, die wie folgt aussehen:
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}}
In welchem:
- Der erste Teil, die eine der ist
RTC_WAKEUP
, RTC
, ELAPSED_WAKEUP
, oder ELAPSED
repräsentiert der type
von Alarm- und entspricht einem ganzzahligen Wert 0-3 bzw.
#0
ist die Nummer des Alarms innerhalb der Charge, wo Zahlen von 0 zu gehen , n-1
wo n
die Anzahl der Alarme im Batch ist. Wenn Ihr Alarm mit anderen gestapelt wird, definiert das am weitesten entfernte "when =" die Zeit, zu der alle Alarme im Batch ausgelöst werden.
4293d358
ist eine interne ID-Nummer, die dem Alarm zugeordnet ist
com.android.chrome
ist der Paketname der Klasse, die den Alarm gesetzt hat
type=1
, die Art des Alarms, siehe erste Kugel oben
whenElapsed=1369361
bezieht sich auf die Anzahl der Millisekunden seit dem Start des Systems, bei der dieser Alarm ausgelöst wird (ungefähr)
when=+19s304ms
bedeutet, dass der Alarm in 19 Sekunden ausgelöst wird, 304 Millisekunden nach dem Zeitpunkt des Aufrufs dumpsys alarm
. Ebenso +2d13h29m03s882ms
bezieht sich ein Wert wie auf eine relative Zeit von 2 Tagen, 13 Stunden, 29 Minuten ... in der Zukunft
window=
bezieht sich auf eine von zwei internen Konstanten, die mit der Methode zu tun haben, mit der der Alarm gestapelt wird. AlarmManager.WINDOW_EXACT=0
und wird eingestellt, wenn der Alarm mit setExact()
oder geplant wird setAlarmClock()
. AlarmManager.WINDOW_HEURISTIC=-1
und wird eingestellt, wenn der Alarm mit geplant ist setInexactRepeating()
. Andernfalls wird der Wert von der API-Version bestimmt. Für API <19 (KitKat) WINDOW_EXACT
wird verwendet und für API> = 19 WINDOW_HEURISTIC
wird verwendet. (Ich musste mich in den AlarmManager.java
Quellcode vertiefen, um das herauszufinden.)
repeatInterval=900000
ist, wie oft der Alarm wiederholt wird, z. B. alle 900000 ms oder 15 Minuten. Ein Wert von 0 bedeutet, dass der Alarm nicht wiederholt wird.
count=
bezieht sich auf die Häufigkeit, mit der ein Alarm hätte ausgelöst werden sollen, jedoch nicht aus irgendeinem Grund. 0 ist hier eine gute Zahl. > 0 bedeutet, dass der Alarm aus irgendeinem Grund übersprungen wurde.
operation=PendingIntent{...}
ist ein Verweis auf das PendingIntent
, was durch den Alarm ausgelöst wird. Abhängig davon, ob der Alarm mit PendingIntent
,, oder instanziiert getService
wurde getBroadcast
, startet der Alarm einen Dienst, sendet eine Sendung oder startet eine oder mehrere Aktivitäten.getActivity
getActivities
F3: Broadcast Ref Count
Um dies und die anderen Ausgabeelemente danach herauszufinden, musste ich mich mit dem AlarmManagerService.java
Quellcode befassen .
Damit einige Alarme funktionieren, muss das Gerät aufgeweckt werden und sollte erst wieder in den Ruhezustand versetzt werden, wenn alle erforderlichen Sendungen gesendet wurden. Die interne Variable mBroadcastRefCount
wird bei 0 initialisiert und erhöht, wenn zu sendende Broadcasts in die Warteschlange gestellt werden. Wenn jede Sendung gesendet wird, wird sie dekrementiert. Wenn sie auf 0 zurückkehrt, wakeLock
wird sie freigegeben und das Gerät kann wieder in den Ruhezustand versetzt werden.
Broadcast Ref Count: 0
bedeutet einfach, dass zum Zeitpunkt der dumpsys alarm
Ausführung keine Sendungen gesendet wurden.
F4: Top-Alarme
Dies sind die zehn häufigsten Alarme, die in absteigender Reihenfolge nach der Gesamtlaufzeit des Alarmcodes geordnet sind. Dies kann verwendet werden, um Alarme zu finden, die die meisten Systemressourcen verbrauchen, z. B. um Prozesse zu finden, bei denen möglicherweise die Batterielebensdauer erschöpft ist.
F5: Alarmstatistik
In diesem Abschnitt werden Statistiken für alle Alarme angezeigt, die seit dem letzten Neustart des Systems ausgeführt wurden. Hier können Sie nachsehen, ob die in der Vergangenheit eingestellten Alarme ausgelöst wurden, ob sie das Telefon aufgeweckt haben usw. Das Format dieser Einträge wird als Nächstes behandelt.
F6: Einträge für Alarmstatistiken
Einträge für Alarmstatistiken sehen folgendermaßen aus:
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}
wo in der ersten Zeile:
com.example.someapp
ist der Paketname des Prozesses, der den Alarm ausgelöst hat
+1s857ms running
ist die gesamte Systemzeit, die von den Prozessen verbraucht wird
0 wakeups
gibt an, wie oft das Gerät durch einen dieser Alarme geweckt wurde
und dann bezieht sich jede Zeile danach auf einen der eingestellten Alarme mit:
+1s817ms
ist die gesamte Systemzeit
0 wakes
ist die Häufigkeit, mit der das Gerät geweckt werden musste
83 alarms
ist die Häufigkeit, mit der der Alarm ausgelöst wurde; Dies ist nur> 1 für wiederholte Alarme
cmp={...}
Der Dienst, der gestartet wurde, als der Alarm ausgelöst wurde
Wenn der Alarm eine Sendung auslöste, könnte der Eintrag alternativ wie folgt aussehen:
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
...
mit:
act=...
ist der Name der Absicht, die ausgestrahlt wurde
Es ist möglich, dass ein Alarm sowohl einen cmp={...}
als auch einen act=...
Eintrag hat, was bedeutet, dass der Alarm sowohl eine Absicht sendet als auch einen Dienst startet.
Zusammenfassung
Das Debuggen von Android-Alarmen mithilfe der Ausgabe von adb shell dumpsys alarm
kann schwierig sein, und es gibt keinen zentralen Ort, an dem die dumpsys
Nachrichten vollständig erklärt werden. Es ist nicht immer ersichtlich, wie Alarme zusammengefügt werden, und manchmal ist es schwierig, einen Dienst oder eine Aktivität genau dann auszulösen, wenn dies gewünscht wird. Hoffentlich ist dies eine nützliche Referenz für Leute, die versuchen, ihre Alarme zu debuggen.