Native threads in standby mode

[ezmora]

I have a number of native threads in my app.
I noticed that when my device is put in a standby mode, all threads
(native as well as Dalvik), pause their running and simply go to
‘sleep’.

I have a number of questions:
1. Is my observation correct? Does putting the device in standby mode
actually pause the entire process (including all Dalvik and native
threads)?

2. When the device is switched back on, how does each thread know from
where to resume its normal flow?

3. How can I force keep my native threads running even when the
device is in standby mode? (is PARTIAL_WAKE_LOCK the right path to
take?)

4. Suppose my threads do not perform CPU intensive operations, what’s
the implication of keeping the native threads running, on the
battery’s life?


Thanks,
Eyal

[David Turner]

On Tue, Jan 17, 2012 at 8:20 AM, ezmora <eyal...@gmail.com> wrote:

I have a number of native threads in my app.
I noticed that when my device is put in a standby mode, all threads
(native as well as Dalvik), pause their running and simply go to
‘sleep’.

I have a number of questions:
1. Is my observation correct? Does putting the device in standby mode
actually pause the entire process (including all Dalvik and native
threads)?

Yes, unless you're holding wakelocks, your process will be paused.

 

2. When the device is switched back on, how does each thread know from
where to resume its normal flow?

The kernel handles this for you, threads don't need to be aware of this.

 

3. How can I force keep my native threads  running even when the
device is in standby mode? (is PARTIAL_WAKE_LOCK the right path to
take?)

Acquiring a wake lock is one way to do it, but you should only do that when performing short important activities where it's critical that you're not paused.

And that's because preventing the system from sleeping for a long time is a sure way to kill your device's battery.

There are platform facilities that can be used if you need to run background code periodically. For example see the Android AlarmManager documentation. Note that there are no native APIs for it, you'll have to do access it through JNI iirc.

 

4. Suppose my threads do not perform CPU intensive operations, what’s
the implication of keeping the native threads running, on the
battery’s life?

If the threads are running, they are CPU intensive by definition. If they are blocked on I/O, they will be paused.

I guess you would like to have your threads paused, waiting for some external event (e.g. a specific network packet being received), and be awoken as soon as this happens.

Unfortunately, this requires a wake lock and is a battery killer. It's much better to program periodic checks through the AlarmManager, and associate your thread with an Android Service.

Hope this helps

 

Thanks,
Eyal

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

[Eyal Zmora]

Thanks for your reply, David.

2 more questions below:

On Tue, Jan 17, 2012 at 11:51 AM, David Turner <di...@android.com> wrote:

On Tue, Jan 17, 2012 at 8:20 AM, ezmora <eyal...@gmail.com> wrote:

I have a number of native threads in my app.
I noticed that when my device is put in a standby mode, all threads
(native as well as Dalvik), pause their running and simply go to
‘sleep’.

I have a number of questions:
1. Is my observation correct? Does putting the device in standby mode
actually pause the entire process (including all Dalvik and native
threads)?

Yes, unless you're holding wakelocks, your process will be paused.

        [Eyal] - Does that include services (which are supposedly tasks which should run in the background), what about broadcast receivers? 

 

2. When the device is switched back on, how does each thread know from
where to resume its normal flow?

The kernel handles this for you, threads don't need to be aware of this.

 

3. How can I force keep my native threads  running even when the
device is in standby mode? (is PARTIAL_WAKE_LOCK the right path to
take?)

Acquiring a wake lock is one way to do it, but you should only do that when performing short important activities where it's critical that you're not paused.

And that's because preventing the system from sleeping for a long time is a sure way to kill your device's battery.

There are platform facilities that can be used if you need to run background code periodically. For example see the Android AlarmManager documentation. Note that there are no native APIs for it, you'll have to do access it through JNI iirc.

 

4. Suppose my threads do not perform CPU intensive operations, what’s
the implication of keeping the native threads running, on the
battery’s life?

If the threads are running, they are CPU intensive by definition. If they are blocked on I/O, they will be paused.

I guess you would like to have your threads paused, waiting for some external event (e.g. a specific network packet being received), and be awoken as soon as this happens.

Unfortunately, this requires a wake lock and is a battery killer. It's much better to program periodic checks through the AlarmManager, and associate your thread with an Android Service.

   [Eyal] -> Not really. I have native threads which act as timers. In others words they sleep until they receive a signal from the kernel (not from an external source). Is that 'CPU intensive' too? I mean they are asleep most of the time...   I know I can find workarounds accessing Java APIs, but I'm trying to avoid it at this stage.