I want to understand the time information on the dumpsys gfxinfo log. It looks like this:
Applications Graphics Acceleration Info:
Uptime: 16264702 Realtime: 28169900
Can anyone tell me how to associate these figures with System.currentTimeMillis()?
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.
Related
When I press the sleep button on the device then turn it back and "update" the uptime shows the time as if the device did not go to sleep.
From Android Reference: SystemClock:
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.
Standard functions like Thread.sleep(millis) and Object.wait(millis) are always available. These functions use the uptimeMillis() clock; if the device enters sleep, the remainder of the time will be postponed until the device wakes up. These synchronous functions may be interrupted with Thread.interrupt(), and you must handle InterruptedException.
--
Seems like your phone is idle or power saving and not technically sleeping...
Assuming the button you are talking about is the "power" or "lock" button, that isn't necessarily putting the device into deep sleep. In fact, looking at the definition of deep sleep (when the uptime counter will stop) I think it would be very rare. The phone will almost certainly keep the CPU running at a low level to monitor for alarm timers and other system scheduled events. If you are wanting to monitor how much time the phone is in "sleep" (screen off, phone locked etc) I suspect you will need to register a broadcast receiver and monitor for those specific events.
take a look at this thread Android - how to receive broadcast intents ACTION_SCREEN_ON/OFF?
also take a look at the power manager
System.currentTimeMillis() is giving wrong time.
It returns time values from 1980
Also time value taken through this function differs from actual time sometimes.
Some sample values returned by the function
315977198121
315965244789
316002166580
315982533137
Yes, time returned by System.currentTimeMillis() can jump around, for example because the device clock may have drifted, and is being reset due to fetching an accurate time from the network
Time as observed through other APIs may also jump around even more, for example due to changing time zones, or due to daylight saving.
(However that doesn't explain why you are seeing times suddenly in the 1980. That frankly sounds like a device error.)
You state that you are using the value to get a duration. That's an error - you should be using SystemClock.elapsedRealtime() for duration calculations.
See the docs at SystemClock, which specifically note:
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.
Try using System.nanoTime() instead of System.currentTimeMillis().
The documentation of System.currentTimeMillis() seems to indicate that it shouldn't be used for calculating time elapsed!
you can create broadcastreceiver on action 'android.intent.action.TIME_SET'. You can know when time on your device change (by another applications).
This question already has answers here:
Get Real Time - Not Device Set Time in android
(3 answers)
Closed 9 years ago.
Is there a clock in devices that returns always a certain time, independent from user time settings and internet connection?
Such a time would be very helpful when checking if a license has expired.
Is there a clock in devices that returns always a certain time, independent from user time settings and internet connection?
No, sorry.
The GPS clock is independent from system clock / time settings and network connection.
You can get a timestamp by requesting a location fix and accessing Location getTime().
Of course, this is not bulletproof for license checking purposes as it can be spoofed as well. #CommonsWare's notes from comments are also worth considering:
Note that this only works on devices that have GPS, where GPS is enabled by the user, where you can get a GPS signal, and for apps where you do not mind asking for the ACCESS_FINE_LOCATION permission. Hence, this is not really "always", though it may suffice for many needs.
There is no time for this usecase.
Here is a list of the available types of time in Android:
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.
When testing our game, that is heavily dependent on System.currentTimeMillis(), we are experiencing an annoying bug.
Our game uses an array of delta timestamps that indicates when certain things should happen. These timestamps matches a piece of music that is being played.
Testing at home gives us no problems at all. It's impossible to reproduce the bug while testing from our home.
But testing while driving around in the car, between cities, gives us sync problems between the timestamps and the music. My best guess is that Android freeze up the system, including the system timer because it's switching network, or looking for a signal?
I've tried inserting a fake hick-up in the game, by making the thread sleep a few seconds when I press a certain button. This freezes the screen (obviously), but everything is still syncing fine when the sleep is over.
The only way to reproduce this bug, is to take a trip by car or bus or train - which of course is most probably where most people will be when playing our game.
The question is of course,
what to do about it?
Does anyone have any ideas?
Read SystemClock.
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.
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.
I think it's better to use System.nanoTime().
Does anyone know of a way to get the time the device has been in sleep? I am trying to get Awake Time for the device battery and I can get the total time since boot using SystemClock, but they do not have a method for sleepTime. If I could get sleep time, I could do totalTime - sleepTime and get the awakeTime, but not sure on how to get sleep time.
Any suggestions?
Thanks
SystemClock.elapsedRealtime() is "the time since the system was booted, and include deep sleep".
SystemClock.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."
Hence, SystemClock.elapsedRealtime()-SystemClock.uptimeMillis() should be the amount of time in "deep sleep".