0
SystemClock.uptimeMillis()

This call from the Android SystemClock will reset back to zero before it 'Maxes Out'

Right now I use this to base off animations, movement etc below is an example of where a reset would essentially freeze my application.

if (currentTime > frameTime + sequenceTime)
{
    frameTime = currentTime;
}

Here lies the problem currentTime is say 50 then the frameTime is set to 50 right? Ideally the currentTimewould increase with the SystemClock.uptimeMillis() but if its reset? The currentTime becomes very small compared to the frameTime How would I go about fixing this or reset the currentTime for all objects?

This is just a small example if I have different objects having a similar dilemma.

Nate-Wilkins
  • 5,158
  • 3
  • 42
  • 60

1 Answers1

0

From my reading of the documentation, the "uptime" clock only gets reset when the device is rebooted. Unless your application ... somehow ... manages to keep running over a reboot, you shouldn't need to worry about the clock resetting.

(On the other hand, if your application does need to do animations that keep going after a reboot, then maybe you should use the 'currentTimeMillis' clock. The Android documentation for SystemClock describes the alternatives.)

The documentation says this "Note: This value may get reset occasionally (before it would otherwise wrap around).".

This doesn't make a lot of sense to me. The clock is a millisecond clock and is returned as a long, so you would not expect it to ever wrap around. (2^64 milliseconds is a very, very long time.) The only explanation I can think of is that some devices use a 32 bit hardware timer to implement this clock ... which is kind of lame.

Stephen C
  • 632,615
  • 86
  • 730
  • 1,096
  • Could you provide a link to where you read that? The javadoc view says: Returns milliseconds since boot, not counting time spent in deep sleep. Note: This value may get reset occasionally (before it would otherwise wrap around). – Nate-Wilkins Aug 07 '12 at 01:43
  • Oh how should I store the time if it doesn't reset? Currently I have a long holding the value but won't that max out? – Nate-Wilkins Aug 07 '12 at 02:03
  • @dnxviral - have you tried to calculate how long it would take to max out? Hint: 2^10N is approximately equal to 10^3N, so 2^64 has 18 digits as a decimal number. – Stephen C Aug 07 '12 at 02:44
  • Also at @Nate , please consider [this Q&A](http://stackoverflow.com/a/13548653) where it's said that on native level, it's really only a 32 bit value which gets cast to a Java `long`. This means that it could get reset after 24.8 (if it's treated as signed 32 bit) or 49.6 (it it's 32 bit unsigned) days. Not including device sleeps. Without further investigation; I'd assume that a large number of apps will show a strange behaviour when this occurs. – class stacker Apr 20 '13 at 09:18