Battery Drain Concerns

[GoogleCodeExporter]

From Issue#19 (Randolph):

"Actually, we had a related discussion in the class regarding TIME_TICK. Prof. 
Schidlowsky mentioned about the Omnidroid drains the battery life of the device 
considerably and I suspected that TIME_TICK has to do with it (needs an actual 
device to prove it with experimentation) because it will be triggered every 
minute. Chris then suggested using 
http://developer.android.com/reference/android/os/Handler.html  instead of 
listening for the system broadcast TIME_TICK intent if it is indeed an issue.

Here is one approach I can think of utilizing the Handler:
1. Replace TimeMonitoringService with something like ActionSchedulerService.
2. During startup, ActionSchedulerService will then query the rules table and 
look for time triggered events. Then it will schedule sending TIME_TICK* 
intents accordingly. Note that the key here is to schedule the sending of the 
intent instead of actually performing the action to prevent action misfires 
(The rule processor will decide if there is something to do or not). We could 
probably use a Set to keep track of the times to trigger during startup to 
avoid sending the TIME_TICK intent at the same time multiple times.
3. Whenever a time related rule is created or modified, we could then send the 
id of the rule or maybe even the new time itself to the ActionSchedulerService.

* The system broadcast intent is android.intent.action.TIME_TICK, which is 
different from Omnidroid's own TIME_TICK intent."

Original issue reported on code.google.com by case.and...@gmail.com on 24 Jun 2010 at 2:36

[GoogleCodeExporter]

Michael, was this from personal experience or developer feedback?  Was there 
any data to indicate the amount of drain on the battery?

If you have a real device you can see what amount of drain is coming from 
Omnidroid by going to "Settings->About Phone->Battery Use".

I think previous developers have raised concern about this, but this could have 
easily been the result of the phones dying faster than expected during 
development and then the assumption that Omnidroid is causing it (without 
substantiating that fact.)

Even with the TIME_TICK monitoring I never saw Omnidroid take up more than 5% 
of my battery life (before I started doing lots of DB processing due to 
Issue#19) despite me utilizing the application considerably for development.  I 
wouldn't expect a user to really notice that their phone is dying 5% faster.

Of course 5% isn't a small amount either, and the suggestions in this post are 
possibly good ideas regardless.

I'd like some hard numbers though.  That way if we have something to compare it 
to when we work on improving.

Original comment by case.and...@gmail.com on 24 Jun 2010 at 3:00

[GoogleCodeExporter]

Original comment by case.and...@gmail.com on 24 Jun 2010 at 3:16

[GoogleCodeExporter]

Original comment by case.and...@gmail.com on 6 Jul 2010 at 2:20

[GoogleCodeExporter]

This was from personal experience.  I know it was omnidroid because I looked at 
the battery use graph and omnidroid was using 8 times more battery than the 
next highest app.  It dwarfed everything else.

This was a while ago so it's possible that it's not an issue anymore.

Original comment by mschidlo...@gmail.com on 13 Jul 2010 at 11:18

[GoogleCodeExporter]

we could disable services if we don't have any rule for it.

Original comment by sv767%ny...@gtempaccount.com on 20 Jul 2010 at 8:20

[GoogleCodeExporter]

Another user complained about this as well.

Original comment by case.and...@gmail.com on 18 Aug 2010 at 7:20

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I also know that the battery is an issue for gps actions.  After you have 
enabled a rule with gps once, no matter if such a rule is enabled or disabled, 
gps signal always stays on.  If it is possible to disable gps with this fix as 
suggested by sv767, that may help here as well.

Original comment by akshah...@gmail.com on 18 Aug 2010 at 7:44

[GoogleCodeExporter]

Original comment by case.and...@gmail.com on 4 Dec 2012 at 5:52

• Changed state: Accepted