web-dev-qa-db-ja.com

「adb Shell dumpsys alarm」出力の読み方

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

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

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

そこで、質問は次のとおりです。

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

    a。 「23」は現在アクティブなスケジュール済みアラームの数ですか？

  2. バッチ{4293d3a8 num = 1 start = 1369361 end = 1407261}：
    RTC＃0：アラーム{4293d358タイプ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。 「タイプ= 1」とはどういう意味ですか？
    e。 「when = + 19s304ms」は、アラームが19秒でトリガーされることを意味しますか？
    f。 「window = -1」とはどういう意味ですか？
    g。 「repeatInterval = 0」は、これが非繰り返しアラームであることを意味していますか？
    h。 「count = 0」は、電話のスリープ状態が原因でこのアラームが延期されなかったことを意味しますか？
    私。 「operation = PendingIntent {...}」は保留中のインテントを表し、アラームによってトリガーされます。

  3. ブロードキャスト参照カウント：0

    a。これは何ですか？

  4. 上位アラーム：

    a。これは何ですか？

  5. + 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ウェイクアップ」とは何ですか-アラームはトリガーされませんでしたか？
    c。 「2アラーム」とは何ですか？
    d。 'com.username.weatherinfo'は、コンテキストフィールドの保留中の意図に与えられたパッケージの名前を表しますか？
    e。 「行為」とは、意図的に送られた行為を意味しますか？
    f。 「cmp」とは何ですか？パッケージ名とクラス名から構成されていることがわかりますが、どこから取得されますか？インテントコンストラクターから？ g。アラームの一部に「act」または「cmp」のみがあるのはなぜですか？ 「cmp」フィールドのないアラームは、暗黙的なブロードキャストインテント用であると想定しています。それでも、「act」フィールドのないアラームがあるのはなぜですか？

  6. アラーム統計：

    a。これは何ですか？

androidadbalarmmanager
61
user3261128

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

Q1：バッチ

_Pending alarm batches: 23
_

アラームはバッチに編成されます。 ドキュメントに記載されているとおり ：

API 19以降、このメソッドに渡されるトリガー時間は不正確なものとして扱われます。アラームはこの時間より前には配信されませんが、しばらくして遅延して配信される場合があります。 OSはこのポリシーを使用して、システム全体で "batch"アラームを一緒に使用し、デバイスが「ウェイクアップ」する必要がある回数を最小限に抑えます。バッテリーの使用を最小限に抑えます。一般的に、近い将来にスケジュールされたアラームは、遠い将来にスケジュールされたアラームである限り、延期されません。

バッチごとに複数のアラームが存在する場合があります。この場合、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 =」は、バッチ内の時間allアラームを定義します。
  • _4293d358_は、アラームに関連付けられた内部ID番号です
  • _com.Android.chrome_は、アラームを設定したクラスのパッケージ名です
  • _type=1_、アラームのタイプ、上記の最初の箇条書きを参照
  • _whenElapsed=1369361_は、システムが起動してからこのアラームがトリガーされるまでのミリ秒数を示します（概算）
  • _when=+19s304ms_は、_dumpsys alarm_が呼び出された時点から304ミリ秒で19秒間にアラームがトリガーされることを意味します。同様に、_+2d13h29m03s882ms_のような値は、2日、13時間、29分などの相対的な時間を指します...
  • _window=_は、アラームがバッチ処理される方法に関係する2つの内部定数のいずれかを指します。 _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=_は、アラームshouldがトリガーされた回数を指しますが、 は何らかの理由でではありませんでした。ここでは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}
_

最初の行の場所：

  • _com.example.someapp_は、アラームをトリガーしたプロセスのパッケージ名です
  • _+1s857ms running_は、プロセスによって消費される合計システム時間です
  • _0 wakeups_は、これらのアラームのいずれかによってデバイスが起動された回数です

そして、その後の各行は、設定されたアラームの1つを参照します。

  • _+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=..._の両方のエントリを含めることができます。つまり、アラームはインテントをブロードキャストし、サービスを開始します。

概要

デバッグAndroid _adb Shell dumpsys alarm_の出力を使用したアラームは注意が必要な場合があり、dumpsysメッセージが完全に説明されている中心的な場所はありません。一緒にバッチ処理され、必要なときにサービスやアクティビティを正確にトリガーすることが困難な場合があります。これは、アラームをデバッグしようとする人々にとって役立つリファレンスになることを願っています。

150
morphatic

アラームにも苦労した人として、ここに2つのヒントがあります。

シェル出力のデバッグ：

  • 負の時間または巨大な時間（例：-2hr57m20s311ms、14d5hr23m07s500ms）が表示されたのは、クロックのタイプを混同したためです（例RTC with ELAPSED）。これはドキュメントで明らかです。 "RTC_WAKEUP: Alarm time in System.currentTimeMillis() " https://developer.Android.com/reference/Android/app/AlarmManager.html#RTC_WAKEUP

  • アラームをリアルタイムで（作成後）キャンセルします。キャンセルを使用します。保留中のインテントをスケジュールした場合、alarmManager.cancel(pendingIntent)とpendingIntent.cancel()の両方が必要です。

5
Jason

Morphaticの答えはあなたが知る必要があるすべてですが、GUIのオープンソースプロジェクトを作成して、同じ情報を視覚的に表示しました。そもそも私にとってはそうだったからです。

https://github.com/Dottorhouse/DumpsysAlarm

1
Dario R.