Partial Wakelock

[Stefano]

Hi,
I have some context where I use "Music Play" to notify me a
particular event (no repeat, no loop). I've noticed that after those
event I get a big battery drain. Using BetterBatteryStats I've seen
that android.MediaPlayer net.dinglisch.android.taskerm.Tasker create
many wakelocks (Count: 7015, 46662s). Is there a way to reduce this ?
Am I doing something wrong ?

(Phone: Samsung Galaxy S II, stock ROM, 2.3.3 Tasker 1.1.1u1m but got
this also with previous version)

Thanks in advance,
Stefano

[Pent]

>   I have some context where I use "Music Play" to notify me a
> particular event (no repeat, no loop). I've noticed that after those
> event I get a big battery drain. Using BetterBatteryStats I've seen
> that android.MediaPlayer net.dinglisch.android.taskerm.Tasker create
> many wakelocks (Count: 7015, 46662s). Is there a way to reduce this ?
> Am I doing something wrong ?

Well, the device has to be kept awake while the audio is playing.
Notice that a wakelock needs to be held *even when the device is on*
in case it's turned off.

Do the wakelocks attributed to that source continue to increase even
when no more music is played ?

Pent

[Stefano]

> Do the wakelocks attributed to that source continue to increase even
> when no more music is played ?

Yes, until I turn off the phone.

[Pent]

> > Do the wakelocks attributed to that source continue to increase even
> > when no more music is played ?
>
> Yes, until I turn off the phone.

OK, I'll make a note but I won't be able to look at this for at least
a few weeks (I'm in the middle of some other major changes).

Pent

[Pent]

> > Do the wakelocks attributed to that source continue to increase even
> > when no more music is played ?
>
> Yes, until I turn off the phone.

But I don't see how it's contributing to extra battery usage if it
stops when you turn off the phone... If the screen is already on, an
app shouldn't use more power just by holding a wakelock.

Pent

[Stefano]

> But I don't see how it's contributing to extra battery usage if it
> stops when you turn off the phone... If the screen is already on, an
> app shouldn't use more power just by holding a wakelock.
>

Sorry for my poor english. Turn off = shutdown. If the screen simply
goes off the phone is still active 'cause of wakelocks. That's why it
use power.

[Pent]

> Sorry for my poor english. Turn off = shutdown. If the screen simply
> goes off the phone is still active 'cause of wakelocks. That's why it
> use power.

Ah, OK.

Pent

[goose]

Just to add a little of my own info related to this...

BetterBatteryStats are giving a lot of folks a ton of insight into
what specifically is draining battery. Taskerm "M", Tasker "E" and
Tasker Userabsent wakelocks are occurring enough to cause concern.
The info below reflects only a short duration, but I assure you it
grows significantly over the course of a full day on battery. I've
been through all my profiles to try and "catch" the culprit (if there
is one), but I couldn't find any looping, etc., that may cause this:

From an alarmdump:

Wake lock Tasker.UserAbsentWakelock: 12s 18ms partial (6 times)
realtime
Wake lock E: 14s 591ms partial (16 times) realtime
Wake lock M: 10s 304ms partial (214 times) realtime

[Pent]

> BetterBatteryStats are giving a lot of folks a ton of insight into
> what specifically is draining battery.  
> Taskerm "M", Tasker "E" and
> Tasker Userabsent wakelocks are occurring enough to cause concern.

A wakelock is not equivalent to 'draining battery'.

Whenever a new event comes in the monitor 'M' has to get a wakelock
while it's processing. Whenever a task is running, the execution
service E has to gt a wakelock while it runs the task. Whenever you
have background checks (e.g. location) the userabsent wakelock is
needed to keep the check going
every time.

Therefore, they occur a lot. If you want tasks to run and events to be
processed while the screen is off, there's no avoiding it.

Note that when the device is already on (not necessarily with the
screen on, Android stays awake itself for a shortwhile after the
display goes off), wakelocks cause *zero* extra battery drain. *Most*
contexts will cause a lot of wakelocks but zero extra battery.
Example: Power context: Android only sends the signal when it's not in
deep sleep. So wakelocks will only accumulate when the device is
already on and have zero battery impact.

Pent

[goose]

Pent, thank you--that clears up quite a few questions I had. I'm sure
this info will be useful to others as well.

[goose]

Pent,

I forgot to ask, do the Monitor, Execution and Userabsent wakelocks
continue under the following conditions:

1) If Tasker is not running in the foreground?
2) If the profile that uses M, E and Userabsent wakelocks is disabled?

Thanks in advance.

> > Pent- Hide quoted text -
>
> - Show quoted text -

[goose]

Bump

On Oct 19, 2:54 pm, goose <beepsilv...@gmail.com> wrote:
> Pent,
>
> I forgot to ask, do the Monitor, Execution and Userabsent wakelocks
> continue under the following conditions:
>
> 1) If Tasker is not running in the foreground?
> 2) If the profile that uses M, E and Userabsent wakelocks is disabled?
>
> Thanks in advance.
>

[Pent]

> I forgot to ask, do the Monitor, Execution and Userabsent wakelocks
> continue under the following conditions:
>
> 1) If Tasker is not running in the foreground?

Yes.

> 2) If the profile that uses M, E and Userabsent wakelocks is disabled?

If you have one disabled profile: you certainly won't get any E's,
virtually certainly won't get any User absents and probably won't get
any M's (less watertight).

Pent

[goose]

Ok Pent, thank you very much!

[Stefano]

I'm still having the same behaviour with version 1.1.1u2m.

[Pent]

> I'm still having the same behaviour with version 1.1.1u2m.

I didn't get a chance to look at it yet.

Pent

[Stefano]

> I didn't get a chance to look at it yet.
>
> Pent

It's ok. Let me know if I can help you providing a log or other
information :)

[Stefano]

I don't know if this is important but that the task that "play" music
is called (with perform task) from the task associated at the profile

[Tim Sylvester]

I have observed the same behavior with 1.2.1u1 on 2.3.6 stock SGS2 (SPH-D710).

I was able to prevent the excess wakelock count/duration by adding a Wait action and a Music Stop action after the Music Play action.  It seems that the Music Play action remains active until explicitly canceled, even without the "loop" option enabled.

[Pent]

> I have observed the same behavior with 1.2.1u1 on 2.3.6 stock SGS2
> (SPH-D710).
>
> I was able to prevent the excess wakelock count/duration by adding a Wait
> action and a Music Stop action after the Music Play action.  It seems that
> the Music Play action remains active until explicitly canceled, even
> without the "loop" option enabled.

Could you send me a log without the Wait and Music Stop ?

http://tasker.dinglisch.net/faq-how.html#x

Thanks,

Pent

[Stefano]

> > I was able to prevent the excess wakelock count/duration by adding a Wait
> > action and a Music Stop action after the Music Play action.  It seems that
> > the Music Play action remains active until explicitly canceled, even
> > without the "loop" option enabled.

In my case this mitigate the excess of wakelock, but there are some
circumstance where I still get an excess of wakelock.
I tryed also adding a Media Control Cmd Stop with the same result.
I'm on stock 2.3.3 SGS2 (don't know if firmware is part of this
behaviour).