Question

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.

Answer 1

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.