Android development to get mobile phone running time

foreword

Yesterday I encountered a problem and needed to judge the time twice. My first reaction at that time was to use System.currentTimeMillis() to judge. Finally, I found that there would be a bug in this way, that is, if the user manually modifies the time, it will be all messed up. So I wonder if there is a time that is only increased but not decreased, and the user cannot modify it? After a check, I found that it really exists, mainly related to SystemClock. Next, I will learn about this class.

SystemClock

All three clocks are valid and they should not be confused:

1. System.currentTimeMillis() is a standard "wall" clock (time and date) representing the number of milliseconds since the epoch. The wall clock can be set by the user or the telephone network (see setCurrentTimeMillis(long)), so the time may jump forward or backward unpredictably. The clock should only be used in situations where real-world correspondence of date and time is important, such as in calendar or alarm applications. The measurement of interval time and elapsed time should use different clocks. If you use System.currentTimeMillis(), consider listening to broadcasts with ACTION_TIME_TICK, ACTION_TIME_CHANGED and ACTION_TIMEZONE_CHANGED when the time changes.

2. uptimeMillis() indicates the time since the system starts, in milliseconds. Returns the time in the non-sleep period from the system startup to the present in the process. This clock stops when the system goes into deep sleep (CPU is off, device goes black, waiting for external input devices). But this clock is not affected by clock adjustments, idling, or other power-saving mechanisms. This is the base point for most interval times, such as Thread.sleep(millls), Object.wait(millis), and System.nanoTime(). This clock is guaranteed to be monotonic and is suitable for detecting intervals that do not include sleep. Most methods that accept a timestamp value think of using the uptimeMillis() clock.

3. elapsedRealtime()  and elapsedRealtimeNanos()  return the time since the system was started, including the time when the device was in deep sleep. The clock is guaranteed to be monotonic and will continue to count even if the CPU is in power saving mode. This clock can be used to measure the time period during which the system may sleep when the time interval is measured.

There are some mechanisms for controlling timed events:

1. The standard functions Thread.sleep(millis) and Object.wait(millis) are always appropriate. This function uses the uptimeMillis() clock; if the device goes to sleep, the remaining time will be delayed until the system wakes up. These synchronization functions may be interrupted with the Thread.interrupt() method, and you must handle InterruptedException .

2. SystemClock.sleep(millis) is a utility function that changes similar to Thread.sleep(millis) , but it ignores InterruptedException . Use this function to generate delays if you don't use Thread.interrupt() because it saves the thread's interrupted state.

3. Handler classes can schedule asynchronous callbacks at absolute or relative times. The handler class object also uses the uptimeMillis() clock and requires an eventloop (normally rendered on any GUI application). The AlarmManager can fire one-time or recurring events to occur even in deep sleep or when your app is not running. Events may be scheduled to occur with your currentTimeMillis() (RTC) opportunity or elapsedRealtime() (ELAPSED_REALTIME) , and cause an intent to broadcast when they occur.

There are several mechanisms to control when events occur:

1. Valid for standard methods such as Thread.sleep(millis)  and Object.wait(millis) , which use the uptimeMillis() clock, if the device goes into deep sleep, the remaining time will be delayed until the system wakes up. These synchronized methods may be interrupted by Thread.interrupt() and you must handle InterruptedException.

2. SystemClock.sleep(millis) is a utility method similar to Thread.sleep(millis) , but it ignores the InterruptedException exception (in fact, Thread.sleep is used, but the exception is handled). Using this function will incur a delay if you don't use Thread.interrupt() because it saves the interrupted state of the thread.

3. The Handler class can set asynchronous callbacks at a relative or absolute time. The Handler object also uses the uptimeMillis() clock and requires a loop (often in GUI programs).

4. AlarmManager can trigger a one-time or recurring event even if the device is in deep sleep or the application is not running. The event can choose to use currentTimeMillis() (RTC) or elapsedRealtime() (ELAPSED_REALTIME) to set the time, when the event occurs, an Intent broadcast will be triggered.

5. public method:

static long currentThreadTimeMillis() Returns the number of milliseconds running on the current thread.

static long elapsedRealtime() Returns the number of milliseconds since the system was started, including the sleep time.

static long elapsedRealtimeNanos() Returns the number of nanoseconds since the system was started, including the sleep time.

static boolean setCurrentTimeMillis(long millis) Sets the current wall clock time in milliseconds. The calling process needs to have the appropriate permissions.

static void sleep(long ms) Waits for the given time (uptimeMillis). Similar to Thread.sleep(millis), but it does not throw InterruptedException. The event is deferred until the next interrupt operation. The method does not return until the specified time has elapsed.

static long uptimeMillis() Returns the millisecond time since the system was started, excluding the sleep time. (The non-sleep period time from the system startup to the present)