From ActivityManagerService.java:
long uptime = SystemClock.uptimeMillis();
long realtime = SystemClock.elapsedRealtime();
pw.println("Applications Graphics Acceleration Info:");
pw.println("Uptime: " + uptime + " Realtime: " + realtime);
Also from SystemClock description:
Three different clocks are available, and they should not be confused:
System.currentTimeMillis()
is the standard "wall" clock (time and
date) expressing milliseconds since the epoch. The wall clock can be
set by the user or the phone network (see setCurrentTimeMillis(long)
),
so the time may jump backwards or forwards unpredictably. This clock
should only be used when correspondence with real-world dates and
times is important, such as in a calendar or alarm clock application.
Interval or elapsed time measurements should use a different clock. If
you are using System.currentTimeMillis()
, consider listening to the
ACTION_TIME_TICK
, ACTION_TIME_CHANGED
and ACTION_TIMEZONE_CHANGED
Intent broadcasts to find out when the time changes.
uptimeMillis()
is counted in milliseconds since the system was booted. This clock stops when the system enters deep sleep (CPU off, display dark, device waiting for external input), but is not affected by clock scaling, idle, or other power saving mechanisms. This is the basis for most interval timing such as Thread.sleep(millls)
, Object.wait(millis)
, and System.nanoTime()
. This clock is guaranteed to be monotonic, and is suitable for interval timing when the interval does not span device sleep. Most methods that accept a timestamp value currently expect the uptimeMillis()
clock.
elapsedRealtime()
and elapsedRealtimeNanos()
return the time since the system was booted, and include deep sleep. This clock is guaranteed to be monotonic, and continues to tick even when the CPU is in power saving modes, so is the recommend basis for general purpose interval timing.