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 »