1

Why on earth does the adb shell dumpsys batterystats command not print regular timestamps? (Like usagestats does for example, or literally anything else on the planet.)

Instead, it gives you a "RESET TIME" within the file, and the lines after that show how much time has passed since that time. "RESET" times mostly appear just once at the beginning, sometimes however they appear multiple times within the log, sometimes even skipping hours, seemingly at random.

And as if that isn't bad enough.. Let me just show a real-life example:

adb shell dumpsys batterystats

Gives me (among other things of course) this:

                0 (9) RESET:TIME: 2020-01-29-01-37-39

Good. So the time starts at 2020-01-29-01-37-39. Alright. Only reset time in the output.

I just turned the screen on. Here is the entry in the log for that:

      +21h44m19s484ms (4) 057 +wake_lock=1000:"PhoneWindowManager.mPowerKeyWakeLock" +screen screenwake=1000:"android.policy:POWER"

Great. +21h44m19s. It is now (well, it was when this happened) 2020-01-30-00-16-00.

"RESET" time of 2020-01-29-01-37-39 + 21h44m19s = 2020-01-29-23-21-58. ?????


Okay, down to my actual questions:

  1. Why does dumpsys batterystats not use normal timestamps?
  2. How does one read those timestamps? They seem beyond broken.
  3. Is there a way to change it to "normal" timestamps?

(My goal is to track when exactly the screen (and optionally WiFi) was on and when it was off. If there is any other way to do that besides batterystats, please leave a comment.)

2 Answers 2

2

This is a partial answer that needs more details through the full dump to understand whats the and read the output of what the system is trying to convey.

The data unit is a number taken from the following list: 1: Number of objects 2: Number of bytes 3: Number of milliseconds 4: Number of allocations 5: Id 6: Percent s: Number of seconds (monotonic time) Default value for data of type int/long is 2 (bytes).

Breaks down to what I think is:

The data unit is a number taken from the following list:

1: Number of objects = (4)

2: Number of bytes {057}

3: Number of milliseconds. +21h44m19s484ms wake_lock=1000 screen screenwake=1000

4: Number of allocations wake_lock=1000, screen screenwake=1000

5: Id. android.policy:POWER

6: Percent s: Number of seconds (monotonic time) Default value for data of type int/long is 2 (bytes).

https://android.googlesource.com/platform/system/core/+/master/logcat/event.logtags

The time value starts at boot to current breaking the time down to.

+21h44m19s484ms First the time since thw device was bopted and reads like:

21h is 21 hours.

44m is 44 minutes

19s is 19 seconds

484ms is 484 milliseconds.

However there is more going on since it reads line by line meaning one line is not the complete story. In order to understand whats going on the full log or dump is crucially needed.

4
  • My question's solely about the timestamps used (I must admit I'm confused by the first part of your answer, but that's not really what I'm asking about anyway). It would indeed make sense if the time value starts at boot (equaling the RESET TIME), but as I said in my question, that can't really be the case. It might be accurate at the beginning of the log, but as in my example it goes off a lot towards the end.
    – confetti
    Feb 2, 2020 at 2:18
  • It not complete it presents like the broke part of the brain reads but gives enough info to tell you what's going on. you can pull more verbose or detailed information through variety of options or log types. I believe you have a bit of tunnel vision preventing you from seeing the how the syntax is presented in a simple way expecting a more complicating answer or reason. Feb 2, 2020 at 2:45
  • I think you do not understand my question.. I'm not really asking about the syntax of the log, or the verbosity, or anything like that. My question is all about "Why does batterystats use +*h*m*s*ms instead of an actual DATETIME stamp?" and why the times it uses doesn't match up. See, it'll say for example boot and reset time was at 1am, then it will say +5h in the log, which would be 6am, right? Except for in reality it was, let's say 6:40. That's what my question is about. The times in the log do not match with the real time.
    – confetti
    Feb 2, 2020 at 3:22
  • Do you have an example of that? Leading to the syntax is very important to the meaning. Feb 2, 2020 at 6:03
2

The energy consumption by Android devices is estimated based on the amount of time certain hardware components are residing in different states (e.g., WIFI ON, WIFI OFF, etc.). For each hardware component, there is a power value for each state of the component provided by the manufacturer. So with the amount of time a hardware component resides in a certain state times the power value, the actual energy consumption is calculated.

Each time a state change is triggered, an event is recorded in the batterystats tool. The batterystats tool collects the events based on a timestamp starting from 0 at the mentioned RESET event.

Your questions:

(1) The timestamps in the batterystats output start from the last reset of the batterystats tool. You can manually reset the timestamp with then batterystats reset command. I don't know what are the exact triggers within the Android system to reset the batterystats, probably when the battery is fully charged.

(2) As you mentionend you have the system time of the RESET event. You read the example +21h44m19s: 21 hours 44 minutes and 19 seconds since the RESET event.

(3) Whatever you mean with "real timestamps" you transform them to any date format you like by adding the batterystats timestamp to the reset time. The batterystats output cannot be changed.

1
  • I did try the adding the timestamps to the reset time, but many many times this does not yield accurate results (e.g. sometimes a timestamp ends up in the future or completely off)
    – confetti
    Oct 24, 2020 at 15:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .