[解決済み] adb shell dumpsys alarm」出力の読み方

2023-07-25 09:41:51

質問

アラームを正しく設定することと、アラームのキャンセルと再スケジュールのメカニズムを理解することに苦労しています。

デバイス上でスケジュールされたすべてのアラームを取得する adb コマンドがあることを発見しましたが、出力の形式を説明するドキュメントを見つけられませんでした。

私はここで多くの説明を求めていることを理解しているので、もし誰かが "adb shell dumpsys alarm" についての詳細な説明を含むリンクを投げてくれるなら、私は本当に感謝します。

では、以下が質問です。

保留中のアラームバッチ 23

a. 23」は現在有効でスケジュールされているアラームの数ですか？
Batch{4293d3a8 num=1 start=1369361 end=1407261}です。

  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}} です。

a. num=1」「start=1369361」「end=1407261」とは何ですか？

b. 'RTC'はRTCアラームの略だと思うのですが。

c. '#0'は何の略でしょうか？

d. type=1」は何を意味するのか？

e. when=+19s304ms」は、19秒後にアラームが鳴るという意味ですか？

f. window=-1'とはどういう意味ですか？

g. repeatInterval=0'は非繰り返しアラームという意味ですか？

h. count=0'は、このアラームが電話のスリープ状態により延期されなかったことを意味しますか？

i. 'operation=PendingIntent{...}' は保留中のインテントを表し、それはアラームによってトリガーされると推測されます。
ブロードキャスト・レフ・カウント 0

a. これは何ですか？
トップアラーム

a. これは何ですか？
+47s271ms実行、0ウェイクアップ、2アラーム：com.username.weatherinfo

act=com.username.receivers.CyclicWeatherUpdater.WEATHER_UPDATE_ACTION

cmp={com.username.weatherinfo/com.username.receivers.CyclicWeatherUpdater} とする。

a. 47s271ms」は、このアラームが47秒後に鳴るという意味ですか？

b. 0 wakeups' とは、アラームが一度も作動しなかったという意味ですか？

c. 2アラーム』とは何ですか？

d. com.username.weatherinfo' はパッケージ名の略で、コンテクストフィールドで保留中のインテントに与えられたものですか？

e. act' はインテントに送信されたアクションを意味していますか？

f. cmp'とは何ですか？パッケージ名とクラス名から構成されているのはわかりますが、どこから取っているのでしょうか？インテンションコンストラクタからですか？ g. アラームの一部が 'act' のみ、または 'cmp' のみである理由は何ですか? cmp」フィールドのないアラームは暗黙のブロードキャストインテント用であると仮定しました。しかし、なぜ'act'フィールドのないアラームがあるのですか?
アラームの統計

a. これは何ですか？

どのように解決するのですか？

このスレッドが古いことは承知していますが、回答は簡単には見つからず、役に立つかもしれません。私は、これらのメッセージが何を意味するのかを理解するためにかなりの時間を費やしました。

Q1: バッチ

Pending alarm batches: 23

アラームはバッチに整理されています。ドキュメントに記載されているように :

API 19以降、このメソッドに渡されたトリガー時刻は不正確なものとして扱われます：アラームはこの時刻より前には配信されませんが、遅延してしばらくしてから配信されることがあります。OSはこのポリシーを使用して、次のことを行います。 バッチ処理に使用されます。 アラームをシステム全体でまとめて、デバイスのウェイクアップの回数を最小限に抑え、バッテリーの使用を最小限に抑えます。一般に、近い将来にスケジュールされたアラームは、遠い将来にスケジュールされたアラームほど長くは延期されません。

バッチごとに1つ以上のアラームがある場合があります。この場合、23個の バッチ のアラームは、おそらく23個より多くのアラームが予定されていることを意味します。その中で dumpsys alarm の出力では、各バッチを説明する行は次のようになります。

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

その中で

4293d3a8 は、バッチに関連する内部 ID です。
num=1 は、このバッチ内のアラームの数です。この場合、バッチ内のアラームは1つだけです。
は start と end の数値は、最後にシステムが再起動されてから経過したミリ秒数を表します。この投稿で説明したまた、バッチ内のアラームがトリガーされる時間のウィンドウをおおまかに表します。

Q2: アラームについて

各アラームは、次のような3行で記述されています。

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

その中で

のいずれかであり、最初の部分は RTC_WAKEUP , RTC , ELAPSED_WAKEUP または ELAPSED を表します。 type のアラームを表し、それぞれ 0 ～ 3 の整数値に対応します。
#0 はバッチ内のアラームの番号で、番号は 0 から n-1 ここで n は、バッチ内のアラームの数です。あなたのアラームが他のアラームとバッチされる場合、最も遠い将来の "when=" がその時刻を定義します。 すべて バッチ内のアラームがトリガーされる時間を定義します。
4293d358 はアラームに関連する内部 ID 番号です。
com.android.chrome はアラームを設定したクラスのパッケージ名です。
type=1 はアラームのタイプで、上記の最初の箇条書きを参照してください。
whenElapsed=1369361 は、このアラームがトリガーされる、システム開始からのミリ秒数を指します (おおよそ)。
when=+19s304ms はアラームが19秒後、304ミリ秒後に発生することを意味します。 dumpsys alarm が呼び出された時刻から 304 ミリ秒後の 19 秒後にアラームが作動することを意味します。同様に、次のような値も +2d13h29m03s882ms は、2 日 13 時間 29 分...先の相対的な時刻を指しています。
window= は、アラームがバッチ処理されるメソッドに関連する 2 つの内部定数のうちの 1 つを指します。 AlarmManager.WINDOW_EXACT=0 でアラームがスケジュールされたときに設定されます。 setExact() または setAlarmClock() . AlarmManager.WINDOW_HEURISTIC=-1 でアラームがスケジュールされたときに設定されます。 setInexactRepeating() . それ以外の場合は、APIのバージョンによって値が決まります。API < 19 (KitKat)の場合。 WINDOW_EXACT が使用され、API >= 19の場合は WINDOW_HEURISTIC が使用されます。(私はを掘り下げると AlarmManager.java ソースコードを参照してください)。
repeatInterval=900000 は、アラームが繰り返される頻度です。例えば、900000msごと、または15分ごとです。値0は、アラームが繰り返されないことを意味します。
count= はアラームの回数を意味します。 べきである が発動されましたが はありませんでした。 というように、何らかの理由でスキップされたことを意味します。ここでは0が良い数字です。 >0は、何らかの理由でアラームがスキップされたことを意味します。
operation=PendingIntent{...} は参照先として PendingIntent への参照であり、アラームによってトリガーされます。によって PendingIntent を使ってインスタンス化されたかどうかによって getService , getBroadcast , getActivity または getActivities の場合、アラームはサービスを開始し、ブロードキャストを送信し、1つまたは複数のアクティビティを開始します。

Q3: ブロードキャスト参照回数

これ以降の出力項目を知るために、私はを掘り下げる必要がありました。 AlarmManagerService.java ソースコード .

いくつかのアラームを動作させるために、デバイスは起こされる必要があり、必要なすべてのブロードキャストが送信されるまで、スリープに戻るべきではありません。内部変数 mBroadcastRefCount は 0 で初期化され、送信されるブロードキャストがキューに入れられるとインクリメントされます。ブロードキャストが送信されるたびにデクリメントされ、0に戻ると wakeLock が解放され、デバイスがスリープに戻っても大丈夫になります。

Broadcast Ref Count: 0 は、単に、その時点で dumpsys alarm が実行された時点では、ブロードキャストを送信している最中ではなかったということです。

Q4: トップアラーム

これは、アラームコードが実行された総集約時間によって降順にランク付けされた上位 10 件のアラームです。これは、システムリソースを最も多く消費しているアラームを見つけるために使用できます。たとえば、バッテリーの寿命を消耗しているプロセスの障害になっている可能性があるものを見つけることができます。

Q5: アラームの統計

このセクションは、システムが最後に再起動されてから実行されたすべてのアラームの統計情報を表示します。ここで、過去に設定したアラームが作動したかどうか、電話を起こしたかどうかなどを確認することができます。これらのエントリの形式は次に説明します。

Q6: アラーム統計の入力項目

アラーム統計のエントリは、次のようなものです。

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}

のところは、1行目に

com.example.someapp はアラームを発生させたプロセスのパッケージ名です。
+1s857ms running は、プロセスによって消費された合計システム時間です。
0 wakeups は、これらのアラームのいずれかによってデバイスが起動された回数です。

で、それ以降の各行は、設定されたアラームの一つを参照しています。

+1s817ms はシステム全体の消費時間
0 wakes はデバイスを起動しなければならなかった回数です。
83 alarms はアラームが作動した回数で、繰り返しアラームの場合は1回となります。
cmp={...} アラームがトリガーされたときに開始されたサービスです。

代わりに、アラームがブロードキャストをトリガーした場合、エントリーは次のようになります。

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

を使っています。

act=... 放送された意図の名前である

アラームに cmp={...} と act=... エントリがあり、アラームはインテントをブロードキャストし、サービスを開始したことを意味します。

概要

の出力を使ってアンドロイドのアラームをデバッグする。 adb shell dumpsys alarm の出力を使ってアンドロイドアラームをデバッグするのは厄介です。 dumpsys メッセージが完全に説明されている中央の場所がありません。アラームがどのようにまとめられるかは必ずしも明らかではありませんし、時にはサービスやアクティビティを希望通りにトリガーさせることが難しい場合もあります。これがアラームのデバッグを試みる人々にとって有用なリファレンスになることを願っています。