TaoK wrote:
>  - If not, are "ACTION_BATTERY_CHANGED" intents the best way to
> monitor for battery drain?

There is also a separate ACTION_BATTERY_LOW Intent, but it is
undocumented how low LOW is.

>  - Does Android really put the CPU to sleep when you lock the phone?

Not necessarily immediately, but yes, the CPU will go to sleep.

>  - Otherwise, how does it decide when to put the CPU to sleep?

When nothing holds a WakeLock (or a native equivalent), I imagine.

>  - How does this CPU sleep affect "naive" simple services?

A sleeping CPU processes no instructions, so those services stop in
their tracks until the CPU starts up again.

>  - How does this CPU sleep affect broadcasted intents such as
> "ACTION_BATTERY_CHANGED" and "ACTION_TIME_TICK"?

I seriously hope ACTION_TIME_TICK is not sent when the CPU is off. I
have no idea about the former.

>  - Can a service "schedule" itself to cause no battery drain for, say,
> 30 minutes, wake up and do something for a second, and sleep for 30
> minutes again (and does this effectively equal zero drain on the
> battery?)

You found part of the answer for this in your followup post.
AlarmManager lets you schedule service work. However, bear in mind that
"something" may take more than a second if it depends on a radio.

Jeff Sharkey's "Coding for Life -- Battery Life, That Is" Google I/O
presentation on power drain was first-rate:

http://wiki.andmob.org/videos

> I recently aquired a Samsung Galaxy i7500 (from Germany, via a mailbox/
> shipping company)

They shipped you a mailbox?

;-)

> Several times, the phone has run out of batteries and turned off, but
> until today I didn't have proof - there is NO AUDIBLE WARNING that the
> phone is running out of battery - how is this possible??

I don't recall audible warnings for low battery on my G1, if that helps.

> Assuming that this is simply a flaw in the OS (on the Galaxy I'm
> running Cupcake/1.5 standard with Google APIs, haven't tried rooting
> it yet), I guess the only solution would be to write a service that
> somehow monitors the battery level and does something when it start
> running low.

The old Power Manager app used to do that, but I think it may have been
lobotomized with the Android 1.5 secure settings changes.

On the other hand, somebody linked to this app today, and it looks
really interesting:

http://www.gearsoft.mobi/wisyncplus.html

> In an (unrelated, location-based) application I'm writing now I use
> the "ACTION_BATTERY_CHANGED" Intent Action with a BroadcastListener to
> find out if the battery is running low (and quit doing expensive GPS
> stuff if that is the case), and that is, or at least seems to be, a
> very easy solution... 

*applause*

> If I'm understanding correctly, even if I ran a service that I didn't
> quit, it would somehow be put to sleep (until the user did something
> to wake up the CPU) unless I did something clever with CPU Wake locks?

Correct. Keeping a service running has more of an impact in terms of
memory consumption than battery consumption, assuming the service is not
being stupid while it's running (e.g., busy-wait in a tight loop).

> Is the "correct" approach a combination of the two?
> 
>  - Service

Yes.

>  - running all the time

Use AlarmManager if possible.

>  - When the phone is awake / active:
>  - checks battery status (or listens for "ACTION_BATTERY_CHANGED"
> intents for a couple minutes) every 5 minutes.
>  - when the phone is asleep: voluntarily puts itself to sleep for 30
> minutes at a time, listens for "ACTION_BATTERY_CHANGED" intents for a
> few minutes, and goes to sleep again.

If you're not using a radio, and not doing much work per alarm cycle, I
wouldn't bother with the ACTION_BATTERY_CHANGED stuff, as you won't be a
major contributor to battery drain. However, the general notion of
scaling things back on low battery is a good implementation idea -- in
fact, I have a tutorial in _Android Programming Tutorials_ just to make
that point.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

Android App Developer Training: http://commonsware.com/training.html

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to