Tungstwenty
commented
11 years ago For the "bad reboots" (if/when you go ahead with this) the obvious suggestion is to mark somewhere that a valid "before_reboot" ref was stored and if upon boot it doesn't exist, invalidate the refs that needed it (such as since_unplugged, since_charged) and fallback to the current behavior.
BTW this possible enhancement has synergies with #223
The problem is indeed related to the fact that BBS does passive monitoring and uses snapshots. Each snapshot (reference) describes the stats of the stats at a given point in time, in terms of counters (e.g. alarms), volumes (network) and times (plus combinations). All those counters are based on userland / kernel counters that do not have any history and are reset at boot.
Now imagine following situation (over simplified):
ref "since unplugged": time = 12:00 alarms a1=500 wakeups, deep sleep = 10 minutes
reading at 12:30: time = 12:30 alarms a1=510 wakeups, deep sleep = 11 minutes -> since unplugged: time=00:30, alarms a1=10, deep sleep = 1 minute
I guess you get the picture.
Now happens a reboot, and all counters are reset to 0. Keeping the previous refs (I could just remove the handling at "on boot").
reading at 13:00: time = 13:00 alarms a1=12 wakeups, deep sleep = 1 minutes -> since unplugged: time=00:30, alarms a1=-488, deep sleep = -9 minute
I guess you get the picture...
What would be needed to support stats with boot in between would be:
Pretty tricky heh? Now add that there are many ways to reboot and not all will be proccessed by ACTION_SHUTDOWN (e.g. removing the battery) so sometimes there will be a continuity in the stats sometimes not.
Now that said I am willing to consider that as a feature and think of a logic to implement that continuity but I hope you understand that it's a little more than just commenting out the deletion of the references at boot.