"adb shell dumpsys alarm"출력을 읽는 방법

"adb shell dumpsys alarm"출력을 읽는 방법

---

알람을 올바르게 설정하고 알람을 취소하고 다시 예약하는 메커니즘을 이해하는 데 어려움을 겪고 있습니다.

기기에 예약 된 모든 알람을 검색하는 adb 명령이 있음을 발견했지만 출력 형식을 설명하는 문서를 찾지 못했습니다.

나는 여기에서 많은 설명을 요구하고 있다는 것을 이해한다. 그래서 누군가 "adb shell dumpsys alarm"에 대한 자세한 설명이있는 링크를 던지면 정말 감사 할 것이다.

따라서 여기에 질문이 있습니다.

1. 보류중인 알람 배치 : 23

   ㅏ. '23'은 현재 활성화되고 예약 된 알람의 수입니까?

2. 일괄 {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}}

   ㅏ. 'num = 1', 'start = 1369361'및 'end = 1407261'은 무엇입니까?
   비. 'RTC'는 RTC 경보를 의미합니다.
   씨. '# 0'은 무엇을 의미합니까?
   디. '유형 = 1'은 무엇을 의미합니까?
   이자형. 'when = + 19s304ms'는 알람이 19 초 후에 발생한다는 의미입니까?
   에프. 'window = -1'은 무엇을 의미합니까?
   지. 'repeatInterval = 0'이 반복되지 않는 알람임을 의미합니까?
   h. 'count = 0'은 전화 절전 상태로 인해이 알람이 연기되지 않았 음을 의미합니까?
   나는. 'operation = PendingIntent {...}'는 알람에 의해 트리거되는 보류중인 의도를 나타냅니다.
   

3. 방송 참조 횟수 : 0

   ㅏ. 이게 뭐야?

4. 상위 경보 :

   ㅏ. 이게 뭐야?

5. + 47s271ms 실행, 깨우기 0 회, 알람 2 개 : com.username.weatherinfo
     act = com.username.receivers.CyclicWeatherUpdater.WEATHER_UPDATE_ACTION
       cmp = {com.username.weatherinfo / com.username.receivers.CyclicWeatherUpdater}

   ㅏ. '+ 47s271ms'는이 알람이 47 초 후에 트리거된다는 의미입니까?
   비. '0 웨이크 업'이란 무엇입니까-알람이 트리거되지 않았습니까?
   씨. '2 개의 알람'이 무엇인가요?
   디. 'com.username.weatherinfo'는 컨텍스트 필드에서 보류중인 의도에 제공된 패키지 이름을 의미합니까?
   이자형. '행위'는 의도를 위해 보낸 행동을 의미합니까?
   에프. 'cmp'는 무엇입니까? 패키지 이름과 클래스 이름으로 구성되어 있지만 어디에서 가져 왔습니까? 의도 생성자에서? 지. 알람의 일부에 'act'만 있거나 'cmp'만있는 이유는 무엇입니까? 나는 'cmp'필드가없는 알람은 암시 적 브로드 캐스트 인 텐트를위한 것이라고 가정했습니다. 그런데 왜 'act'필드가없는 알람이 있는가?

6. 알람 통계 :

   ㅏ. 이게 뭐야?

---

이 스레드가 오래되었다는 것을 알고 있지만 답변을 찾기가 쉽지 않으며 유용 할 수 있습니다. 이 메시지가 의미하는 바를 알아 내기 위해 많은 시간을 보냈습니다.

Q1 : 배치

Pending alarm batches: 23

경보는 배치로 구성됩니다. 문서에 설명 된대로 :

API 19부터이 메서드에 전달 된 트리거 시간은 정확하지 않은 것으로 처리됩니다.이 시간 이전에는 경보가 전달되지 않지만 나중에 지연되고 전달 될 수 있습니다. OS는이 정책을 사용 하여 전체 시스템에서 알람을 함께 "일괄 처리" 하여 장치가 "깨어나야하는"횟수를 최소화하고 배터리 사용을 최소화합니다. 일반적으로 가까운 미래에 예약 된 경보는 먼 미래에 예약 된 경보만큼 연기되지 않습니다.

배치 당 하나 이상의 알람이있을 수 있습니다. 이 경우에는 23 개의 알람 배치 가 있으며 이는 아마도 23 개 이상의 알람이 예약되어 있음을 의미합니다. 에서 dumpsys alarm출력, 각 배치를 설명하는 라인과 같다 :

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

여기에서 :

• 4293d3a8 배치와 관련된 내부 ID입니다.
• num=1이 배치의 경보 수입니다. 이 경우 배치에 경보가 하나만 있습니다.
• start및 end번호는 시스템으로 마지막으로 재부팅 된 이후 경과 된 시간을 밀리 초 단위로 표현 이 게시물에 설명 하고, 또한 대략 일괄 경보가 트리거되어야하는 시간 창을 표현합니다.

Q2 : 알람

각 경보는 다음과 같은 세 줄로 설명됩니다.

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 means the alarm will be triggered in 19 seconds, 304 milliseconds from the time when dumpsys alarm was called. Likewise, a value like +2d13h29m03s882ms refers to a relative time 2 days, 13 hours, 29 minutes... in the future
• window= refers to one of two internal constants having to do with the method in which the alarm is batched. AlarmManager.WINDOW_EXACT=0 and is set when the alarm is scheduled with setExact() or setAlarmClock(). AlarmManager.WINDOW_HEURISTIC=-1 and is set when the alarm is scheduled with setInexactRepeating(). Otherwise, the value is determined by the API version. For API < 19 (KitKat), WINDOW_EXACT is used and for API >= 19, WINDOW_HEURISTIC is used. (I had to dig into the AlarmManager.java source code to figure this out.)
• repeatInterval=900000 is how often the alarm repeats, e.g. every 900000ms or 15 minutes. A value of 0 means the alarm does not repeat.
• count= refers to the number of times that an alarm should have been triggered, but wasn't for some reason. 0 is a good number here. >0 means the alarm was skipped for some reason.
• operation=PendingIntent{...} is a reference to the PendingIntent that gets triggered by the alarm. Depending on whether the PendingIntent was instantiated using getService, getBroadcast, getActivity, or getActivities, the alarm will start a service, send a broadcast, or start one or more activities.

Q3: Broadcast Ref Count

To find out about this and the other output items after this I had to dig into the AlarmManagerService.java source code.

In order for some alarms to work the device has to be woken up, and should not go back to sleep until all necessary broadcasts have been sent. The internal variable mBroadcastRefCount is initialized at 0 and is incremented as broadcasts to be sent are queued up. As each broadcast is sent it is decremented and when it gets back to 0, the wakeLock is released and it is okay for the device to go back to sleep.

Broadcast Ref Count: 0 simply means that at the time that dumpsys alarm was run, it was not in the middle of sending any broadcasts.

Q4: Top Alarms

This is the top ten alarms ranked in descending order by total aggregate time that the alarm code has run. This can be used to find alarms that are consuming the greatest amount of system resources, e.g. to find processes that may be at fault for draining battery life.

Q5: Alarm Stats

This section shows stats for all of the alarms that have run since the system was last restarted. This is where you can look to see if the alarms you set in the past have been triggered, if they woke the phone up, etc. The format of these entries is covered next.

Q6: Alarm Stats Entries

Alarm stats entries look like:

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}

where in the first line:

• com.example.someapp is the package name of the process that triggered the alarm
• +1s857ms running is the total system time consumed by the processes
• 0 wakeups is the number of times the device was woken by one of these alarms

and then each line after that refers to one of the alarms that was set, with:

• +1s817ms is total system time consumed
• 0 wakes is the number of times the device had to be woken up
• 83 alarms is the number of times the alarm has been triggered; this will only be >1 for repeating alarms
• cmp={...} the service that was started when the alarm was triggered

Alternatively, if the alarm triggered a broadcast, the entry might look like:

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

with:

• act=... being the name of the intention that was broadcast

It is possible for an alarm to have both a cmp={...} and a act=... entry, meaning the alarm both broadcast an intent and started a service.

Summary

Debugging android alarms using the output of adb shell dumpsys alarm can be tricky, and there is no central location where the dumpsys messages are fully explained. It is not always apparent how alarms get batched together, and sometimes it's difficult to get a service or activity to be triggered exactly when desired. Hopefully this will be useful reference for people trying to debug their alarms.

---

As someone who also struggled with alarms, here are two tips:

Debugging shell output:

• seeing negative or huge times (eg. -2hr57m20s311ms, 14d5hr23m07s500ms), was because I confused the type of clock (eg. RTC with ELAPSED). This is clear in documentation, "RTC_WAKEUP: Alarm time in System.currentTimeMillis()" https://developer.android.com/reference/android/app/AlarmManager.html#RTC_WAKEUP

• canceling alarms in real-time (after creating) them. Use the cancel, which if you scheduled a pending intent needs both: alarmManager.cancel(pendingIntent) and pendingIntent.cancel()

---

Even though morphatic's answer is all you need to know, I've created an open source project for a GUI to show the same information in a visual way. I think it could be useful for others, since it has been for me in the first place.

https://github.com/Dottorhouse/DumpsysAlarm

참고URL : https://stackoverflow.com/questions/28742884/how-to-read-adb-shell-dumpsys-alarm-output