Timers/pthread condition variables in NDK

979 views
Skip to first unread message

music

unread,
Sep 17, 2011, 12:33:11 PM9/17/11
to android-ndk
Hello,

I see a behaviour on my application which has a lot of native code. I
wanted to confirm whether this is the expected behaviour.

My application needs to wake up every 10 minutes to send something to
the backend server. In order to wake up, inside the native code, I use
my own timers, which are implemented using pthread_cond_timedwait.
Basically, it will wait for the next timer to fire off, then it starts
waiting for the next set of timers and so on. It works fine on other
posix based systems as well as Android for the most part.

However, what i see that, when the device is sleeping, these timers
are not getting fired on time. I do not use any power locks and when i
just tired using partial wake locks, the problem goes away. But I
suspect, the battery life would be horrendous and i don't like the end
user warning about the app taking up too much battery.

My question is:

1. Is the right approach in this case is to use AlarmManager to set
timers and have an interface from native code to manage it?
2. Is there any way to get notification of some sort when the device
goes to sleep?
3. What is the logic on the system side to sleep?
4. If I get an alarm manager timer fired, should I hold a wake lock
during its execution to not go back to sleep or is it guaranteed by
the system.
5. Finally, why doesn't the condition variable wait timeout wake up
the cpu? shouldn't it?

Any help is appreciated.

RichardC

unread,
Sep 17, 2011, 7:11:27 PM9/17/11
to android-ndk
I think the Alarm Manager approach is your best bet.

However, do you really need to wake the phone every 10 mins? Have a
look at setInexactRepeating method of AlarmManager and its "no wake"
alarms. Remember the phone may take 1 min to go back to sleep so even
a short task can drastically effect the battery life.

Dianne Hackborn

unread,
Sep 18, 2011, 12:20:37 PM9/18/11
to andro...@googlegroups.com
You need to use the alarm manager to wake up.  If you are going to be doing any work outside of the onReceive() of the broadcast you have registered with the alarm manager, you need to use a PowerManager wake lock to keep the CPU from sleeping.

Wake locks are an important part of Android's power management, so that it can aggressively put the device into a deep sleep state.  If nobody is holding a wake lock it will go into this state, and only a few things will bring it back out (interrupts from some physical buttons, alarms that are scheduled, events from the phone CPU, etc).

There is no notification about going in and out of this sleep state.

There is a broadcast about turning the screen on and off (the screen being on also implicitly holds a wake lock), but that is not relevant to what you are asking here.


--
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.

music mobile

unread,
Sep 18, 2011, 6:32:50 PM9/18/11
to andro...@googlegroups.com
Thanks so much Dianne and Richard. I will implement AlarmManager to do this periodic timers. It seems consistent with my understanding.
 
However, is there any plans to do a more standard based approach, which is if you are not running any application code, the device will sleep eventually? (In this case, if the pthread_cond_wait is a system call and so no application code is running and the device should sleep eventually).
 
--thanks
Najeeb

Dianne Hackborn

unread,
Sep 18, 2011, 6:46:48 PM9/18/11
to andro...@googlegroups.com
I don't know what you mean by that being standard.  One what operating system does an application (even just the current foreground application) sitting blocked in the kernel mean that the device will go to deep sleep if it waits there long enough?

music mobile

unread,
Sep 19, 2011, 6:03:09 PM9/19/11
to andro...@googlegroups.com
most other systems i am working on (specifically blackberry and Nokia. iPhone is totally different), I think the device enters a low power state after periods of inactivity (meaning I call into some system and I am not running any application code). Now, I am not sure whether that is an IDLE, SLEEP or DEEP SLEEP. In no situation, I would miss the firing of a timer because the system is in a power save mode. That is what I meant by this being non-standard. Now, if this helps the overall user experience it is great. But my question is that couldn't you have made the deep sleep mode work with condition variable wait in this instance? If AlarmManager or an incoming data on socket could wake up the device, why couldn't pthread_cond_wait timeout?
 
btw, thanks for your answers on this forum. It is great.

Dianne Hackborn

unread,
Sep 19, 2011, 10:16:40 PM9/19/11
to andro...@googlegroups.com
I really don't understand what you are saying.  The behavior of Android for activity is not at all unusual: if there is no user activity after a certain amount of time, the screen is turned off.

Android does have a different behavior while the screen is off for going into deep sleep, with applications using wake locks to tell it that it needs to remain running.  If you don't hold a (partial) wake lock, you don't need the CPU to remain running, and it can stop at any point.

This is good, it allows the CPU to be powered down much more aggressively than if you were relying on applications to be very carefully written to go into blocking calls that won't wake up for any extraneous reason.

This is actually really good for app developers as well, because you can write code that more power efficient.  For example there are many places in Android where some operation will be performed at a point in the future, but no wake lock is held, because we don't care about the exact time it happens, and wouldn't want to waste the battery by waking up the device for it.

This also allows the system to go automatically go into a very low-power state -- when no wake locks are held it can completely turn off the application CPU, because only external events (alarms, incoming networking traffic, physical key presses, etc) are going to wake it up.

music mobile

unread,
Sep 20, 2011, 3:15:13 AM9/20/11
to andro...@googlegroups.com
you don't seem to understand me, but yet you answered my questions :)
 
But If an application has set a timeout for a condition variable, it means the app cares about it, even if Android system doesn't. I would have expected Android to have the intelligence (or a particular power save mode other than keeping the cpu awake all the time) to wake up the app when it needs to run the app code, after the timeout happens on the kernel resource. Why can't you implement this the same way you implemented AlarmManager? At a future point, wake up the app.
 
Now for all the timers in the native code, i need to have jni access to alarm manager that runs alarms on Java side and appropriate callbacks are sent to the native side, while the same code has worked on multiple mobile platforms with no issues. But i understand the rationale here that there s more aggressive power save modes in Android. But regardless, that is non standard.
 
On Mon, Sep 19, 2011 at 7:16 PM, Dianne Hackborn <hac...@android.com> wrote:
I really don't understand what you are saying.  The behavior of Android for activity is not at all unusual: if there is no user activity after a certain amount of time, the screen is turned off

Dianne Hackborn

unread,
Sep 20, 2011, 3:36:15 AM9/20/11
to andro...@googlegroups.com
We don't WANT that.  We WANT applications to be explicit about when they need to keep the device from sleeping.  I can promise you, if things worked like you request, you would notice the impact on battery.

And we aren't talking about keeping the CPU awake all of the time.  A partial wake lock prevents the application processor from going into *deep* sleep.  That is, not running at all, completely unpowered, until an external event wakes it up.  If the CPU just doesn't have anything to do, it will be put to sleep regardless of there being a wake lock until the next time there is something for the kernel to do.

music mobile

unread,
Sep 20, 2011, 3:53:54 AM9/20/11
to andro...@googlegroups.com
Thanks. While we are at it, do you recommend alarm manager to be used for all timers, since we don't know when cpu can go to sleep?
 
Remember mine is a background service based app that needs to run periodically to register with backend service. For example, I have timers that are scheduled in the native code anywhere from 200 milliseconds to 2 hours. Is there an additional overhead in using Alarm Manager?
 
From the time the screen is turned off, is there a minimum time before the CPU can go to sleep? If I knew that i could use my current timers within that duration and for longer timers i could use Alarm manager.

Dianne Hackborn

unread,
Oct 1, 2011, 9:03:50 PM10/1/11
to andro...@googlegroups.com
On Tue, Sep 20, 2011 at 12:53 AM, music mobile <mobilemu...@gmail.com> wrote:
Thanks. While we are at it, do you recommend alarm manager to be used for all timers, since we don't know when cpu can go to sleep?

Only for things you actually need to wake the device up for.  If you look at the platform and apps, the vast majority of timing is just done with handlers and such, because it doesn't want to keep the CPU awake -- for example this is used for all timing of animations, timeouts for user interaction (such as detecting a long press), etc.
 
Remember mine is a background service based app that needs to run periodically to register with backend service. For example, I have timers that are scheduled in the native code anywhere from 200 milliseconds to 2 hours. Is there an additional overhead in using Alarm Manager?

There is certainly more overhead for the alarm manager, because you need to do an IPC to it, and it then needs to enqueue your request and update the alarm driver, then when the alarm goes off it needs to execute the pending intent.

For something that is happening every 2 hours (or every 15 minutes), though, that overhead is insignificant.

For every 200 milliseconds?  No you don't want to use the alarm manager.  More than that, you don't want to do *anything* that will keep the CPU on because you will kill the battery making it wake up every 200ms and running your code that much.
 
From the time the screen is turned off, is there a minimum time before the CPU can go to sleep? If I knew that i could use my current timers within that duration and for longer timers i could use Alarm manager.

No, the CPU can turn off at any point after the screen is off.

Neta Zmora

unread,
Oct 2, 2011, 5:04:18 AM10/2/11
to android-ndk
Hi Dianne,

I've read this email thread and I understand your concerns about the
application needlessly waking up the device.
However, we have a native application that _must_ wake up the device
every so often (with reasonable precision).
Is there a native API to wake up the device after a timeout expires,
or must I use the Java AlarmManager class (which will complicate our
native code because it will have to invoke Java code). In other words,
I am looking for something equivalent to pthread_cond_timedwait which
will explicitly work when the device is awake _and_ when the device
sleeping.

Thanks,
Neta


On Sep 20, 9:36 am, Dianne Hackborn <hack...@android.com> wrote:
> We don't WANT that.  We WANT applications to be explicit about when they
> need to keep the device from sleeping.  I can promise you, if things worked
> like you request, you would notice the impact on battery.
>
> And we aren't talking about keeping the CPU awake all of the time.  A
> partial wake lock prevents the application processor from going into *deep*
> sleep.  That is, not running at all, completely unpowered, until an external
> event wakes it up.  If the CPU just doesn't have anything to do, it will be
> put to sleep regardless of there being a wake lock until the next time there
> is something for the kernel to do.
>
> On Tue, Sep 20, 2011 at 12:15 AM, music mobile
> <mobilemusicsh...@gmail.com>wrote:
>
>
>
>
>
>
>
> > you don't seem to understand me, but yet you answered my questions :)
>
> > But If an application has set a timeout for a condition variable, it means
> > the app cares about it, even if Android system doesn't. I would have
> > expected Android to have the intelligence (or a particular power save mode
> > other than keeping the cpu awake all the time) to wake up the app when it
> > needs to run the app code, after the timeout happens on the kernel resource.
> > Why can't you implement this the same way you implemented AlarmManager? At a
> > future point, wake up the app.
>
> > Now for all the timers in the native code, i need to have jni access to
> > alarm manager that runs alarms on Java side and appropriate callbacks are
> > sent to the native side, while the same code has worked on multiple mobile
> > platforms with no issues. But i understand the rationale here that there s
> > more aggressive power save modes in Android. But regardless, that is non
> > standard.
>
> > On Mon, Sep 19, 2011 at 7:16 PM, Dianne Hackborn <hack...@android.com>wrote:
>
> >> I really don't understand what you are saying.  The behavior of Android
> >> for activity is not at all unusual: if there is no user activity after a
> >> certain amount of time, the screen is turned off
> >> Android does have a different behavior while the screen is off for going
> >> into deep sleep, with applications using wake locks to tell it that it needs
> >> to remain running.  If you don't hold a (partial) wake lock, you don't need
> >> the CPU to remain running, and it can stop at any point.
>
> >> This is good, it allows the CPU to be powered down much more aggressively
> >> than if you were relying on applications to be very carefully written to go
> >> into blocking calls that won't wake up for any extraneous reason.
>
> >> This is actually really good for app developers as well, because you can
> >> write code that more power efficient.  For example there are many places in
> >> Android where some operation will be performed at a point in the future, but
> >> no wake lock is held, because we don't care about the exact time it happens,
> >> and wouldn't want to waste the battery by waking up the device for it.
>
> >> This also allows the system to go automatically go into a very low-power
> >> state -- when no wake locks are held it can completely turn off the
> >> application CPU, because only external events (alarms, incoming networking
> >> traffic, physical key presses, etc) are going to wake it up.
>
> >>   On Mon, Sep 19, 2011 at 3:03 PM, music mobile <
> >> mobilemusicsh...@gmail.com> wrote:
>
> >>>   most other systems i am working on (specifically blackberry and Nokia.
> >>> iPhone is totally different), I think the device enters a low power state
> >>> after periods of inactivity (meaning I call into some system and I am not
> >>> running any application code). Now, I am not sure whether that is an IDLE,
> >>> SLEEP or DEEP SLEEP. In no situation, I would miss the firing of a timer
> >>> because the system is in a power save mode. That is what I meant by this
> >>> being non-standard. Now, if this helps the overall user experience it is
> >>> great. But my question is that couldn't you have made the deep sleep mode
> >>> work with condition variable wait in this instance? If AlarmManager or an
> >>> incoming data on socket could wake up the device, why couldn't
> >>> pthread_cond_wait timeout?
>
> >>> btw, thanks for your answers on this forum. It is great.
> >>>    On Sun, Sep 18, 2011 at 3:46 PM, Dianne Hackborn <hack...@android.com
> >>> > wrote:
>
> >>>> I don't know what you mean by that being standard.  One what operating
> >>>> system does an application (even just the current foreground application)
> >>>> sitting blocked in the kernel mean that the device will go to deep sleep if
> >>>> it waits there long enough?
>
> >>>>   On Sun, Sep 18, 2011 at 3:32 PM, music mobile <
> >>>> mobilemusicsh...@gmail.com> wrote:
>
> >>>>>   Thanks so much Dianne and Richard. I will implement AlarmManager to
> >>>>> do this periodic timers. It seems consistent with my understanding.
>
> >>>>> However, is there any plans to do a more standard based approach, which
> >>>>> is if you are not running any application code, the device will sleep
> >>>>> eventually? (In this case, if the pthread_cond_wait is a system call and so
> >>>>> no application code is running and the device should sleep eventually).
>
> >>>>> --thanks
> >>>>> Najeeb
>
> >>>>>   On Sun, Sep 18, 2011 at 9:20 AM, Dianne Hackborn <
> >>>>> hack...@android.com> wrote:
>
> >>>>>>  You need to use the alarm manager to wake up.  If you are going to
> >>>>>> be doing any work outside of the onReceive() of the broadcast you have
> >>>>>> registered with the alarm manager, you need to use a PowerManager wake lock
> >>>>>> to keep the CPU from sleeping.
>
> >>>>>> Wake locks are an important part of Android's power management, so
> >>>>>> that it can aggressively put the device into a deep sleep state.  If nobody
> >>>>>> is holding a wake lock it will go into this state, and only a few things
> >>>>>> will bring it back out (interrupts from some physical buttons, alarms that
> >>>>>> are scheduled, events from the phone CPU, etc).
>
> >>>>>> There is no notification about going in and out of this sleep state.
>
> >>>>>> There is a broadcast about turning the screen on and off (the screen
> >>>>>> being on also implicitly holds a wake lock), but that is not relevant to
> >>>>>> what you are asking here.
>
> >>>>>> hack...@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.
>
> >>>>>>   --
> >>>>>> 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.
>
> >>>>> --
> >>>>> 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
> >>>> hack...@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.
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups
>
> ...
>
> read more »

David Turner

unread,
Oct 2, 2011, 12:33:21 PM10/2/11
to andro...@googlegroups.com
On Sun, Oct 2, 2011 at 2:04 AM, Neta Zmora <neta....@gmail.com> wrote:
Hi Dianne,

I've read this email thread and I understand your concerns about the
application needlessly waking up the device.
However, we have a native application that _must_ wake up the device
every so often (with reasonable precision).
Is there a native API to wake up the device after a timeout expires,
or must I use the Java AlarmManager class (which will complicate our
native code because it will have to invoke Java code). In other words,
I am looking for something equivalent to pthread_cond_timedwait which
will explicitly work when the device is awake _and_ when the device
sleeping.

There is no such native API to do that. You will have to call the VM through JNI if you want to anything like this.

Dianne Hackborn

unread,
Oct 2, 2011, 8:31:13 PM10/2/11
to andro...@googlegroups.com
And you'll need to declare a broadcast receiver in your manifest for the alarm manager to launch when the alarm goes off, whose implementation uses JNI to call back to your native code.

And keep in mind that between the time you schedule the alarm to when it goes off, your process may have been killed, so this may involve re-launching the process with this receiver being the first thing that runs in it.

Zoran Angelov

unread,
Oct 3, 2011, 10:51:34 AM10/3/11
to andro...@googlegroups.com
Hi music,
I've found this info about android wake_locks :

At least it can help you to understand how android wake_locks are implemented/working.



music

unread,
Oct 12, 2011, 6:09:04 PM10/12/11
to android-ndk
I just came back to the thread after all these days and just saw all
the messages. I reworked my app to use AlarmManager and handlers
selectively and it is all working fine.

> For every 200 milliseconds? No you don't want to use the alarm manager.
> More than that, you don't want to do *anything* that will keep the CPU on
> because you will kill the battery making it wake up every 200ms and running
> your code that much.

I know that. I have been doing this for a while. :) That is the range
I use, but 200ms timers are not periodic timers, they are based on
some network activity. The problem is that there is no guarantee that
even the short handler based timers will run since the device can
sleep anytime. So, for short timers, I am holding the wake lock and
then scheduling them. It works reliably now. But, I am not sure what
the impact is of acquiring and releasing wake locks. Regardless, it is
quite a bit of unnecessary circus, app developers have to do. With a
bunch of apps holding wake locks at various times, the device is never
going to sleep at this rate. so at the end of the day, not sure
whether it is all worth it from a platform standpoint. anyways, my
problem is solved for now. thanks for your help.

On Oct 1, 6:03 pm, Dianne Hackborn <hack...@android.com> wrote:
> On Tue, Sep 20, 2011 at 12:53 AM, music mobile
> <mobilemusicsh...@gmail.com>wrote:
> hack...@android.com

Dianne Hackborn

unread,
Oct 13, 2011, 5:30:37 PM10/13/11
to andro...@googlegroups.com
It is true that there is no simple API from the NDK, but acquiring and releasing wake locks from Java is a couple lines of code.  Once you write the NDK wrappers, it is a couple lines there as well.

Your assertion that when applications do the right things with wake locks that they become useless because they are always held, though, is flat-out wrong.  You can verify this just by looking at the running vs. realtime on your device -- while the screen is off, in typical operation the cpu will be kept awake due to wake locks less than 10% of the time.

In fact, you will find that if you do hold wake locks for large amount of times, you very noticeable impact battery life.  The amount of impact varies between devices, but on those like the Nexus S (where holding a wake lock has some impact by itself on CPU power use), this is definitely significant.

--
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

Glenn Kasten

unread,
May 2, 2013, 11:43:14 PM5/2/13
to andro...@googlegroups.com
What Dianne and Digit said (all postings by them on this thread). 

On Wednesday, May 1, 2013 6:57:52 AM UTC-7, Venu wrote:
Hi,

Any update on direct API for this?
While googling, I saw setting clock of pthread_cond variable to 'CLOCK_BOOTTIME_ALARM' MAY solve the issue.
Any updates on latest Android versions.

Ran Shalit

unread,
Jan 13, 2017, 1:32:06 AM1/13/17
to android-ndk
Hello,

I know it is old thread, but I have the exact need:
We need to do periodic task in ndk, and get back to sleep.
It seems that there is no ndk api for this purpose yet..., 
so we must implement jni interface for that or maybe we can use the mentioned "CLOCK_BOOTTIME_ALARM" as alternative ?
Can it be used to wake cpu from suspend mode ?
I'm not sure because I think it is not using /dev/alarm, Right ?

Thank you!
Ran

Ran Shalit

unread,
Jan 13, 2017, 10:26:28 AM1/13/17
to andro...@googlegroups.com
Hi Again,

Just wanted to update that I tried using ""CLOCK_BOOTTIME_ALARM"", and
it seems to work OK :)
1. The device gets into suspend between alarms
2. and alarms (using CLOCK_BOOTTIME_ALARM) awakes the device !

Thanks,
Ran
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "android-ndk" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/android-ndk/YCXyzj2Ugck/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> android-ndk...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-ndk.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/android-ndk/9b04006e-eb2a-492d-a66d-0ca50f7e077b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages