How can SystemClock.uptimeMillis () crash?

Question

Android docs in uptimeMillis () say:

Returns the milliseconds since loading, not counting the time spent in deep sleep. Note This value can sometimes appear reset (before it otherwise turns around).

It seems rather strange that the documents worry about it ever wrap around. In the end, the method returns long. A quick calculation suggests that it will take approximately 292,271,022 years for him to ever turn around.

So what about the documents? Is it really possible to wrap it? Can a value wrap before it reaches its maximum value for a long time? Is this what the documents are actually trying to say? And if so, when will this happen?

---

[This is especially perplexing, since System.currentTimeMillis () is also long, which represents time from the era. However, Android absolutely does not mention the possibility of transferring value. Especially for uptimeMillis, which starts with 0 ...]

Answer 1

This is basically a hypothesis, but it seems to make sense based on the documents I found. If you take into account that the native public static long uptimeMillis() in SystemClock is a native method working in 32-bit space, and then it just throws itself into Java long when you call it, then that makes sense, because 2 ^ 32 milliseconds are very easy to reach.