LibreTasks
LibreTasks copied to clipboard
biotinker
Battery Drain Concerns
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 [email protected] on 24 Jun 2010 at 2:36
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 [email protected] on 24 Jun 2010 at 3:00
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 [email protected] on 13 Jul 2010 at 11:18
we could disable services if we don't have any rule for it.
Original comment by sv767%[email protected] on 20 Jul 2010 at 8:20
Another user complained about this as well.
Original comment by [email protected] on 18 Aug 2010 at 7:20
- Added labels: Priority-High
- Removed labels: Priority-Medium
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 [email protected] on 18 Aug 2010 at 7:44
