Keeping track of time independent of the system clock

[Bryan Ashby]

Our product requires keeping track of time independent of the system
clock. This is required as the user may change the time or even go
into a new time zone yet we need to know "our" time. We have
traditionally done this via NTP then use a system timer to calculate
ms since the last refresh (e.g. time = last_ntp + ms_since then). On
Android we can do this via CLOCK_MONOTONIC. However, when the device
goes to sleep this clock stops ticking.

Is there a CLOCK_MONOTONIC like clock that keeps going when the device
sleeps? The requirements are:

1) System time/clock/zone independent. If changing the system clock or
time interfears, it can't be used for this task.
2) Ability to keep track of ticks/ms/etc. across device sleeping
3) High res: At least ms like resolution. I could probably change some
things to use second resolution, but I'd like ms or better.

I'm asking in the NDK group as I'm currently doing this via C/C++. If
there is a Java alternative, that would work too.

[Dianne Hackborn]

SystemClock.elapsedRealtime() continues increasing when the device is asleep.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Bryan Ashby]

Thank you, that should be perfect.

[Bryan Ashby]

Out of curiosity, do you happen to know if this is the same as
clock_gettime() with CLOCK_REALTIME?

[Dianne Hackborn]

Unfortunately, this uses some android-specific magic.  I'll show you where the implementation is, but obviously this is relying on private so shouldn't be used in an app:

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=libs/utils/SystemClock.cpp;h=2bdc0ce278a4708501c97bae835afca8f64acdf4;hb=HEAD#l104

This definitely seems like something that deserves to have an NDK API.

[Bryan Ashby]

Thank you again, extremely helpful. You certainly have my vote for a
public NDK API here. For now JNI can work, but of course will add some
drift.

On Nov 15, 6:34 pm, Dianne Hackborn <hack...@android.com> wrote:
> Unfortunately, this uses some android-specific magic.  I'll show you where
> the implementation is, but obviously this is relying on private so shouldn't
> be used in an app:
>

> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;...

>
> This definitely seems like something that deserves to have an NDK API.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Rick Kawala]

Dianne Hackborn <hackbod <at> android.com> writes:

> Unfortunately, this uses some android-specific magic.

When I look at the .cpp file you posted, it looks like there are two possible
sources of failure in elapsedRealtime(): (1) /dev/alarm doesn't exist, and (2)
the ioctl(ANDROID_ALARM_GET_TIME(ANDROID_ALARM_ELAPSED_REALTIME)) might fail. In
those cases the system clock (which the user can change) is used as a fallback.
I'm wondering if I can depend on /dev/alarm and the ioctl being in place and
working across the hundreds of Android devices out there. Is this something that
everyone's going to implement, or is this something that various manufacturers
have decided to ignore?

Thanks,
Rick