I have an observation concerning how Android handles scheduled events
and would like any suggestions, comments, or feedback on how other
developers have handled this behavior in Android.
I have noticed that there does not appear to be anyway to schedule an
event to happen at "regularly" scheduled times. By regularly scheduled
times I mean a long-lived service/schedule that must run every "n"
minutes. For instance, an application that must check the status of a
web service at user specified intervals (like every 10 minutes).
I have tried a writing a service to run in the background using
Context.startService, Android stops that service after a few minutes.
And, there are many senior Android developers that recommend using the
"alarm that starts a service" method for this type of application. My
testing on Context.StartService would tend to agree. My best results
have been using an alarm to start a service, although the results are
still less than stellar.
I have done weeks of testing trying to get Android to run a service
every 10 minutes (or even close to 10 minutes) using the "Alarm that
starts a service" method. The best I can get in a 24 our period for an
alarm scheduled every 10 miutes is about 75% (110 out of 144 repeating
alarms). I have tried varying this interval from 1 minute to 30
minutes with the same result. I have tested on a non-rooted T-Mobile
both 1.0 and 1.1 firmware. I have tested on an ADP using both 1.0 and
1.1 firmware. I have tried using "PARTIAL_WAKE_LOCK" and
"FULL_WAKE_LOCK" feature of the PowerManager. Nothing seems to work.
Android just will not run an event consistently.
I had high hopes for the repeating alarm that starts a service, but it
seems Android always skips many of the scheduled alarms. I am
beginning to think that "Reguarly" scheduled events is not even
possible in Android.
I'm looking for any comments and suggestions from developers and
Android engineers.
clarkbriancarl wrote: > The best I can get in a 24 our period for an > alarm scheduled every 10 miutes is about 75% (110 out of 144 repeating > alarms). I have tried varying this interval from 1 minute to 30 > minutes with the same result. I have tested on a non-rooted T-Mobile > both 1.0 and 1.1 firmware. I have tested on an ADP using both 1.0 and > 1.1 firmware. I have tried using "PARTIAL_WAKE_LOCK" and > "FULL_WAKE_LOCK" feature of the PowerManager. Nothing seems to work. > Android just will not run an event consistently.
Post an issue to http://b.android.com with sample source code that demonstrates the problem. If you want, reply on this thread with a link to your issue.
-- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available!
THanks for the reply. I use your book as a reference from time to
time. I would recommend it to anyone reading this.
Before I open an issue, I would like to hear from other developers to
see if their experiences have been similar, and if not, do some code
comparison to see what they are doing different. I just want to make
sure this is an issue and not a mistake on my part.
I am willing to post some code if it is needed.
On Mar 27, 10:18 am, Mark Murphy <mmur...@commonsware.com> wrote:
> clarkbriancarl wrote:
> > The best I can get in a 24 our period for an
> > alarm scheduled every 10 miutes is about 75% (110 out of 144 repeating
> > alarms). I have tried varying this interval from 1 minute to 30
> > minutes with the same result. I have tested on a non-rooted T-Mobile
> > both 1.0 and 1.1 firmware. I have tested on an ADP using both 1.0 and
> > 1.1 firmware. I have tried using "PARTIAL_WAKE_LOCK" and
> > "FULL_WAKE_LOCK" feature of the PowerManager. Nothing seems to work.
> > Android just will not run an event consistently.
> Post an issue tohttp://b.android.comwith sample source code that
> demonstrates the problem. If you want, reply on this thread with a link
> to your issue.
> --
> Mark Murphy (a Commons Guy)http://commonsware.com > _The Busy Coder's Guide to Android Development_ Version 2.0 Available!
clarkbriancarl wrote: > THanks for the reply. I use your book as a reference from time to > time. I would recommend it to anyone reading this.
Thanks!
> Before I open an issue, I would like to hear from other developers to > see if their experiences have been similar, and if not, do some code > comparison to see what they are doing different. I just want to make > sure this is an issue and not a mistake on my part.
> I am willing to post some code if it is needed.
I'm sure there are some folk who could eyeball some sample code and point out possible problems but may not have source they are in position to upload. That's one of the many advantages of having sample projects that reproduce possible bugs.
Your issue illustrates, though, that I need to beef up my AlarmService section in the Advanced Android book, so I'll try to spend some time reproducing your scenario and seeing if I get similar results. To invert the Stones, "Ti-i-i-ime is not on my side (no it ain't)", but I'll hopefully be able to squeeze this in this weekend.
> clarkbriancarl wrote:
> > THanks for the reply. I use your book as a reference from time to
> > time. I would recommend it to anyone reading this.
> Thanks!
> > Before I open an issue, I would like to hear from other developers to
> > see if their experiences have been similar, and if not, do some code
> > comparison to see what they are doing different. I just want to make
> > sure this is an issue and not a mistake on my part.
> > I am willing to post some code if it is needed.
> I'm sure there are some folk who could eyeball some sample code and
> point out possible problems but may not have source they are in position
> to upload. That's one of the many advantages of having sample projects
> that reproduce possible bugs.
> Your issue illustrates, though, that I need to beef up my AlarmService
> section in the Advanced Android book, so I'll try to spend some time
> reproducing your scenario and seeing if I get similar results. To invert
> the Stones, "Ti-i-i-ime is not on my side (no it ain't)", but I'll
> hopefully be able to squeeze this in this weekend.
And are you using a partial wake lock? Note that if you absolutely need to
run even when the device is asleep, this can be a little tricky -- you need
to deliver the alarm to a broadcast receive (the alarm manager holds a wake
lock during this time), acquire a partial wake lock there and start your
service and don't release the wake lock until the service is done with its
work.
This is unfortunately tricky to do right now; in the future we would really
like to make wakelock management easier for these situations.
On Fri, Mar 27, 2009 at 10:10 AM, Mariano Kamp <mariano.k...@gmail.com>wrote:
> Hard to judge without any code.
> Do you use AlarmManager.RTC_WAKEUP?
> On Fri, Mar 27, 2009 at 5:45 PM, Mark Murphy <mmur...@commonsware.com>wrote:
>> clarkbriancarl wrote:
>> > THanks for the reply. I use your book as a reference from time to
>> > time. I would recommend it to anyone reading this.
>> Thanks!
>> > Before I open an issue, I would like to hear from other developers to
>> > see if their experiences have been similar, and if not, do some code
>> > comparison to see what they are doing different. I just want to make
>> > sure this is an issue and not a mistake on my part.
>> > I am willing to post some code if it is needed.
>> I'm sure there are some folk who could eyeball some sample code and
>> point out possible problems but may not have source they are in position
>> to upload. That's one of the many advantages of having sample projects
>> that reproduce possible bugs.
>> Your issue illustrates, though, that I need to beef up my AlarmService
>> section in the Advanced Android book, so I'll try to spend some time
>> reproducing your scenario and seeing if I get similar results. To invert
>> the Stones, "Ti-i-i-ime is not on my side (no it ain't)", but I'll
>> hopefully be able to squeeze this in this weekend.
Note: please don't send private questions to me, as I don't have time to
provide private support. All such questions should be posted on public
forums, where I and others can see and answer them.
> And are you using a partial wake lock? Note that if you absolutely need to
> run even when the device is asleep, this can be a little tricky -- you need
> to deliver the alarm to a broadcast receive (the alarm manager holds a wake
> lock during this time), acquire a partial wake lock there and start your
> service and don't release the wake lock until the service is done with its
> work.
> This is unfortunately tricky to do right now; in the future we would really
> like to make wakelock management easier for these situations.
> On Fri, Mar 27, 2009 at 10:10 AM, Mariano Kamp <mariano.k...@gmail.com>wrote:
> > Hard to judge without any code.
> > Do you use AlarmManager.RTC_WAKEUP?
> > On Fri, Mar 27, 2009 at 5:45 PM, Mark Murphy <mmur...@commonsware.com>wrote:
> >> clarkbriancarl wrote:
> >> > THanks for the reply. I use your book as a reference from time to
> >> > time. I would recommend it to anyone reading this.
> >> Thanks!
> >> > Before I open an issue, I would like to hear from other developers to
> >> > see if their experiences have been similar, and if not, do some code
> >> > comparison to see what they are doing different. I just want to make
> >> > sure this is an issue and not a mistake on my part.
> >> > I am willing to post some code if it is needed.
> >> I'm sure there are some folk who could eyeball some sample code and
> >> point out possible problems but may not have source they are in position
> >> to upload. That's one of the many advantages of having sample projects
> >> that reproduce possible bugs.
> >> Your issue illustrates, though, that I need to beef up my AlarmService
> >> section in the Advanced Android book, so I'll try to spend some time
> >> reproducing your scenario and seeing if I get similar results. To invert
> >> the Stones, "Ti-i-i-ime is not on my side (no it ain't)", but I'll
> >> hopefully be able to squeeze this in this weekend.
> Note: please don't send private questions to me, as I don't have time to
> provide private support. All such questions should be posted on public
> forums, where I and others can see and answer them.- Hide quoted text -
Please read again my explanation about what you need to do to keep the
device from going to sleep -- you need to have the alarm sent to a broadcast
receiver, which immediately acquires a partial wake lock, which then starts
the service, and the partial wake lock is not released until the service
completes its work.
Your code has two holes in wake locks: (1) the broadcast can complete before
the service is started, (2) you aren't taking the wake lock until your
thread is running, so even if (1) was not a problem you could still end up
with the system releasing its wake lock before your thread is running.
Also, please look at the API demos for alarms and services. You want to
deliver Intent to the service's onStart(), and use that to schedule work in
the service.
On Fri, Mar 27, 2009 at 2:14 PM, clarkbriancarl <clarkbrianc...@gmail.com>wrote:
> I have used both AlarmManager.ELAPSED_REALTIME_WAKEUP and
> AlarmManager.RTC_WAKEUP.
> I am currently setting a repeating alarm "attached" to a pending
> intent in the GUI portion of the application. The pending intent
> starts the service.
> objPendingIntent = PendingIntent.getService(bServiceGUI.this, 0, new
> Intent(bServiceGUI.this, bService.class), 0);
> On Mar 27, 1:34 pm, Dianne Hackborn <hack...@android.com> wrote:
> > And are you using a partial wake lock? Note that if you absolutely need
> to
> > run even when the device is asleep, this can be a little tricky -- you
> need
> > to deliver the alarm to a broadcast receive (the alarm manager holds a
> wake
> > lock during this time), acquire a partial wake lock there and start your
> > service and don't release the wake lock until the service is done with
> its
> > work.
> > This is unfortunately tricky to do right now; in the future we would
> really
> > like to make wakelock management easier for these situations.
> > On Fri, Mar 27, 2009 at 10:10 AM, Mariano Kamp <mariano.k...@gmail.com
> >wrote:
> > > Hard to judge without any code.
> > > Do you use AlarmManager.RTC_WAKEUP?
> > > On Fri, Mar 27, 2009 at 5:45 PM, Mark Murphy <mmur...@commonsware.com
> >wrote:
> > >> clarkbriancarl wrote:
> > >> > THanks for the reply. I use your book as a reference from time to
> > >> > time. I would recommend it to anyone reading this.
> > >> Thanks!
> > >> > Before I open an issue, I would like to hear from other developers
> to
> > >> > see if their experiences have been similar, and if not, do some code
> > >> > comparison to see what they are doing different. I just want to make
> > >> > sure this is an issue and not a mistake on my part.
> > >> > I am willing to post some code if it is needed.
> > >> I'm sure there are some folk who could eyeball some sample code and
> > >> point out possible problems but may not have source they are in
> position
> > >> to upload. That's one of the many advantages of having sample projects
> > >> that reproduce possible bugs.
> > >> Your issue illustrates, though, that I need to beef up my AlarmService
> > >> section in the Advanced Android book, so I'll try to spend some time
> > >> reproducing your scenario and seeing if I get similar results. To
> invert
> > >> the Stones, "Ti-i-i-ime is not on my side (no it ain't)", but I'll
> > >> hopefully be able to squeeze this in this weekend.
> > Note: please don't send private questions to me, as I don't have time to
> > provide private support. All such questions should be posted on public
> > forums, where I and others can see and answer them.- Hide quoted text -
Note: please don't send private questions to me, as I don't have time to
provide private support. All such questions should be posted on public
forums, where I and others can see and answer them.
Dianne Hackborn wrote: > This is unfortunately tricky to do right now; in the future we would > really like to make wakelock management easier for these situations.
You ain't just whistlin' "Dixie" -- it took me a while to figure out how to implement it, and that was even *after* you described the pattern. Heaven help me if I'd've been trying to noodle that out independently.
I need another day or two to make sure I've solved clarkbriancarl's issues, then I'll write something up.
Thanks!
-- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available!
On Fri, Mar 27, 2009 at 5:03 PM, Mark Murphy <mmur...@commonsware.com>wrote:
> You ain't just whistlin' "Dixie" -- it took me a while to figure out how > to implement it, and that was even *after* you described the pattern. > Heaven help me if I'd've been trying to noodle that out independently.
Yeah this needs to be improved. A lot of the standard platform applications have had bugs in this area in one form or another, too.
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
I am very much looking forward to Mark's writeup. I think that the theory is
sound, but that it is ugly to pass in the wake lock in practice. I use a
static member for that and it makes my eyes bleed. And it makes it harder to
handle cases where start is called more than once.
On Sat, Mar 28, 2009 at 2:53 AM, Dianne Hackborn <hack...@android.com>wrote:
> On Fri, Mar 27, 2009 at 5:03 PM, Mark Murphy <mmur...@commonsware.com>wrote:
>> You ain't just whistlin' "Dixie" -- it took me a while to figure out how
>> to implement it, and that was even *after* you described the pattern.
>> Heaven help me if I'd've been trying to noodle that out independently.
> Yeah this needs to be improved. A lot of the standard platform
> applications have had bugs in this area in one form or another, too.
> Note: please don't send private questions to me, as I don't have time to
> provide private support. All such questions should be posted on public
> forums, where I and others can see and answer them.
Mariano Kamp wrote: > I use a static member for that and it makes my eyes bleed.
Umm...hmm...well...er...
If you want your service to completely go away between alarms, you need your BroadcastReceiver to be registered via the manifest, rather than tied into the system via registerReceiver() in the service. The latter approach would likely keep the Service referenced and kept from being garbage collected.
Given that, we now need to allocate a WakeLock in a BroadcastReceiver and get it over to a newly-minted Service. WakeLock is not Parcelable. Hence, I see no way to get the WakeLock to the Service except through some static data member, somewhere. Whether that is a member on the Service, on the BroadcastReceiver, or in some third class is an implementation detail.
On the other hand, using registerReceiver() would allow you to keep the WakeLock in the Service object without the static data member. It's a trade-off -- if your alarm will fire frequently enough, it might be better to keep the Service around rather than reallocating it all the time. If your alarm is rather infrequent, though, I'd think it would be better to let the Service go away and get reallocated when the alarm fires.
I'll be writing up the infrequent-alarm case (even though my sample code will probably have the alarm going off every 5 minutes or so, just to provide more rapid feedback to those playing with the code).
The good news, though, is that Ms. Hackborn's technique works great -- haven't missed an alarm in 12 hours (every 5 minutes), and the device definitely has been asleep between alarms, given the battery level.
> And > it makes it harder to handle cases where start is called more than once.
That problem can be dealt with, despite the static data member. Though I'll need to beef up my sample some for this scenario -- I was thinking the service would be long since wrapped up before the next alarm fired.
There is one more thing I'd like to add that I think you haven't covered yet
... and probably don't need to, but I want you to be aware of that.
I have an app that synchronizes with Google Reader every hour (alarm) and
also the user can run a sync manually. So both need the background service
to run and as I need to keep partial wake locks end-to-end in both cases I
need to instantiate a wake lock and pass it to the service.
In comparison this adds the possibility that the service is started when it
is already running.
As an example: You press a sync button that triggers the service by calling
start, passing a freshly acquired wake lock to the service. This service
keeps running for a couple of minutes until it is done syncing and then
calls stopSelf().
During that time the alarm kicks in, the broad cast receiver acquires
another wake lock and passes it to the service and starts it.
Now you would have two active wake locks and actually when using a naive
approach to a static variable you would have overwritten the old wake lock,
which would lead to the old lock not being releases which would lead to the
phone not shutting down.
Does that make sense? The short story is, passing in a wake lock using a
naive approach of a static variable doesn't work when the service can be
started again during its runtime. You would need to have some code around it
(passInWakeLock()), that would understand that there is an active wake lock
already and discard (and release) the newly passed in wake lock.
In practice I haven't seen a problem with the time between the end of the
broad cast receiver and the starting of the service.
Cheers,
Mariano
On Sat, Mar 28, 2009 at 12:48 PM, Mark Murphy <mmur...@commonsware.com>wrote:
> Mariano Kamp wrote:
> > I use a static member for that and it makes my eyes bleed.
> Umm...hmm...well...er...
> If you want your service to completely go away between alarms, you need
> your BroadcastReceiver to be registered via the manifest, rather than
> tied into the system via registerReceiver() in the service. The latter
> approach would likely keep the Service referenced and kept from being
> garbage collected.
> Given that, we now need to allocate a WakeLock in a BroadcastReceiver
> and get it over to a newly-minted Service. WakeLock is not Parcelable.
> Hence, I see no way to get the WakeLock to the Service except through
> some static data member, somewhere. Whether that is a member on the
> Service, on the BroadcastReceiver, or in some third class is an
> implementation detail.
> On the other hand, using registerReceiver() would allow you to keep the
> WakeLock in the Service object without the static data member. It's a
> trade-off -- if your alarm will fire frequently enough, it might be
> better to keep the Service around rather than reallocating it all the
> time. If your alarm is rather infrequent, though, I'd think it would be
> better to let the Service go away and get reallocated when the alarm fires.
> I'll be writing up the infrequent-alarm case (even though my sample code
> will probably have the alarm going off every 5 minutes or so, just to
> provide more rapid feedback to those playing with the code).
> The good news, though, is that Ms. Hackborn's technique works great --
> haven't missed an alarm in 12 hours (every 5 minutes), and the device
> definitely has been asleep between alarms, given the battery level.
> > And
> > it makes it harder to handle cases where start is called more than once.
> That problem can be dealt with, despite the static data member. Though
> I'll need to beef up my sample some for this scenario -- I was thinking
> the service would be long since wrapped up before the next alarm fired.
Mariano Kamp wrote: > Now you would have two active wake locks and actually when using a naive > approach to a static variable you would have overwritten the old wake > lock, which would lead to the old lock not being releases which would > lead to the phone not shutting down.
Have you tried using setReferenceCounted(true) on the WakeLock? From a glance at the WakeLock code, you should not need to have two WakeLocks in your case -- one reference-counted WakeLock should suffice.
In the scenario you described:
-- The activity tells the service, "yo! sync me!"
-- The service acquires the reference-counted WakeLock (count now = 1)
-- The alarm goes off and starts the service
-- The started service acquires the *same* reference-counted WakeLock (count now = 2)
-- The work from the activity-initiated sync wraps up and releases the WakeLock (count now = 1 and we are still locked)
-- The work from the alarm wraps up and releases the WakeLock (count now = 0 and the lock is truly released)
Admittedly, this is all theoretical, as I haven't tried reference counted WakeLocks, though I think I'm going to give that a shot here.
> The short story is, passing in a wake lock using a > naive approach of a static variable doesn't work when the service can be > started again during its runtime.
That depends on what your static variable holds. ;-)
On Sat, Mar 28, 2009 at 4:37 PM, Mark Murphy <mmur...@commonsware.com>wrote:
> Have you tried using setReferenceCounted(true) on the WakeLock?
No, I didn't know about that. Sounds interesting. Thanks for the pointer.
> In the scenario you described:
> -- The activity tells the service, "yo! sync me!"
> -- The service acquires the reference-counted WakeLock (count now = 1)
> -- The alarm goes off and starts the service
> -- The started service acquires the *same* reference-counted WakeLock > (count now = 2)
> -- The work from the activity-initiated sync wraps up and releases the > WakeLock (count now = 1 and we are still locked)
Acquiring the wake lock in the service might be ok in the real world, but conceptually this is too late. The OS could have put the phone to sleep between the alarm going off and the service acquiring the wake lock.
Mariano Kamp wrote: > On Sat, Mar 28, 2009 at 4:37 PM, Mark Murphy <mmur...@commonsware.com > <mailto:mmur...@commonsware.com>> wrote:
> Have you tried using setReferenceCounted(true) on the WakeLock?
> No, I didn't know about that. Sounds interesting. Thanks for the pointer.
> In the scenario you described:
> -- The activity tells the service, "yo! sync me!"
> -- The service acquires the reference-counted WakeLock (count now = 1)
> -- The alarm goes off and starts the service
> -- The started service acquires the *same* reference-counted WakeLock > (count now = 2)
> -- The work from the activity-initiated sync wraps up and releases the > WakeLock (count now = 1 and we are still locked)
> Acquiring the wake lock in the service might be ok in the real world, > but conceptually this is too late. The OS could have put the phone to > sleep between the alarm going off and the service acquiring the wake lock.
Ah, yeah, right -- the stuff I already have going. The BroadcastReceiver needs to have access to the WakeLock. If this is a registerReceiver() case, it can use the same object without resorting to a static data member; otherwise, it'll still need one.
I'm working on this stuff right now.
Well, OK, not right now, since I'm typing this reply, but I'll be working on it again as soon as I send this. Assuming, of course, that my personal wake lock doesn't lapsZzzzzzzzzzzzzzzzzzzzzzzzzzzzzz...
First, don't use registerReceiver(). Having a service always running is a
-huge- waste of resources. In fact this will probably be
counter-productive, because as the system gets low on resource and starts
struggling to see what it can free up, it will see your service having
sitting there run for a long long time and start considering it a tempting
candidate for the kill. (If nothing else, because long running processes
often have leaks or just memory fragmentation in them, so killing them and
letting them restart at some point in the future can free up memory even
after they are running again.)
Yes you need to use a global variable for the wake lock. Gross, but it
works.
Please look at the ApiDemo for Service Start Arguments. This shows how a
service can have work coming from multiple client via startService() and
correctly manage its lifecycle to stop itself when it is done and there is
no more incoming work. (The key is stopSelf(int id).) So your intent
receiver can start the service, and your app can also do so.
On Sat, Mar 28, 2009 at 9:17 AM, Mark Murphy <mmur...@commonsware.com>wrote:
> Mariano Kamp wrote:
> > On Sat, Mar 28, 2009 at 4:37 PM, Mark Murphy <mmur...@commonsware.com
> > <mailto:mmur...@commonsware.com>> wrote:
> > Have you tried using setReferenceCounted(true) on the WakeLock?
> > No, I didn't know about that. Sounds interesting. Thanks for the pointer.
> > In the scenario you described:
> > -- The activity tells the service, "yo! sync me!"
> > -- The service acquires the reference-counted WakeLock (count now =
> 1)
> > -- The alarm goes off and starts the service
> > -- The started service acquires the *same* reference-counted WakeLock
> > (count now = 2)
> > -- The work from the activity-initiated sync wraps up and releases
> the
> > WakeLock (count now = 1 and we are still locked)
> > Acquiring the wake lock in the service might be ok in the real world,
> > but conceptually this is too late. The OS could have put the phone to
> > sleep between the alarm going off and the service acquiring the wake
> lock.
> Ah, yeah, right -- the stuff I already have going. The BroadcastReceiver
> needs to have access to the WakeLock. If this is a registerReceiver()
> case, it can use the same object without resorting to a static data
> member; otherwise, it'll still need one.
> I'm working on this stuff right now.
> Well, OK, not right now, since I'm typing this reply, but I'll be
> working on it again as soon as I send this. Assuming, of course, that my
> personal wake lock doesn't lapsZzzzzzzzzzzzzzzzzzzzzzzzzzzzzz...
Note: please don't send private questions to me, as I don't have time to
provide private support. All such questions should be posted on public
forums, where I and others can see and answer them.
[NOTE: If you found this message in the archives and are reading it after June 1, 2009, please visit http://commonsware.com/AdvAndroid/ and download the source code from the link provided there, as the code probably has changed]
It needs more testing, particularly for Mr. Kamp's scenario, but I think it has a chance of holding up. Note that if you try building it, adjust default.properties to reflect your SDK location, and you'll need an SD card (or card image in the emulator).
The goal behind this example is to demonstrate what a lot of people have been requesting: cron-style functionality. Meaning, a scheduler should trigger their code on a fixed interval, including from the point when the device boots, and should cause the code to run even if the device is otherwise asleep. It also attempts to handle Mr. Kamp's scenario where the same logic might also be invoked beyond just the scheduler, and where the logic might sometimes run longer than the alarm period.
When installed, it will set up a RECEIVE_BOOT_COMPLETED BroadcastReceiver, which in turn will set up an AlarmManager ELAPSED_REALTIME_WAKEUP alarm set to recur at five minute intervals.
The app's "purpose" is to add an entry to a running log file on the SD card (placed there for simplicity when testing on a device).
The actual work to log the data to the file is done by a WakeWorkManager. This class manages a background thread for a service with automatic WakeLock management for background work. It wraps a LinkedBlockingQueue and, so long as there is work in the queue, keeps a partial WakeLock. This allows the service (and the BroadcastReceiver that starts the service upon an alarm) to "fire and forget" -- work will get done and the service will stop when everything is done, with a WakeLock ensuring the device will run only as long as is needed.
The service/BroadcastReceiver pair needs a second WakeLock to ensure that everything stays awake long enough to pop the work into the work manager. However, this second WakeLock is then released (the "forget" part of "fire and forget"). This second WakeLock is a static data member on the service class, which, as Ms. Hackborn indicates, seems unavoidable in the current Android SDK. C'est la vie.
Right now, the WakeWorkManager uses only a single background thread. If jobs will routinely take longer than the alarm period (e.g., slow data transfer), you'll probably want more than one thread. Implementation of this is left as an exercise for the reader.
I am definitely up for comments, particularly if you see that I am screwing up WakeLocks or whatnot. Either reply on this thread or join the cw-android Google Group and chime in there.
Thanks to all who contributed ideas and insights, on this thread (e.g., Ms. Hackborn, Mr. Kamp) and on past threads (e.g., Jon Culverson).
I just wanted to thank the both of you for your help on this. Your
suggestions worked beautifully. My application has been running
several hours on two different phones and it has not missed a
scheduled event yet.
Just in case the two of you don't hear this enough, I for one, truly
appreciate the both of you. Between all of Dianne and Mark's hard work
on these groups and all of the work Mark has done with his
"downloadable" sample code on commonsware.com (and Mark's book that I
use regularly).
Thanks to you both!!!
On Mar 28, 2:46 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> [NOTE: If you found this message in the archives and are reading it
> after June 1, 2009, please visithttp://commonsware.com/AdvAndroid/and > download the source code from the link provided there, as the code
> probably has changed]
> It needs more testing, particularly for Mr. Kamp's scenario, but I think
> it has a chance of holding up. Note that if you try building it, adjust
> default.properties to reflect your SDK location, and you'll need an SD
> card (or card image in the emulator).
> The goal behind this example is to demonstrate what a lot of people have
> been requesting: cron-style functionality. Meaning, a scheduler should
> trigger their code on a fixed interval, including from the point when
> the device boots, and should cause the code to run even if the device is
> otherwise asleep. It also attempts to handle Mr. Kamp's scenario where
> the same logic might also be invoked beyond just the scheduler, and
> where the logic might sometimes run longer than the alarm period.
> When installed, it will set up a RECEIVE_BOOT_COMPLETED
> BroadcastReceiver, which in turn will set up an AlarmManager
> ELAPSED_REALTIME_WAKEUP alarm set to recur at five minute intervals.
> The app's "purpose" is to add an entry to a running log file on the SD
> card (placed there for simplicity when testing on a device).
> The actual work to log the data to the file is done by a
> WakeWorkManager. This class manages a background thread for a service
> with automatic WakeLock management for background work. It wraps a
> LinkedBlockingQueue and, so long as there is work in the queue, keeps a
> partial WakeLock. This allows the service (and the BroadcastReceiver
> that starts the service upon an alarm) to "fire and forget" -- work will
> get done and the service will stop when everything is done, with a
> WakeLock ensuring the device will run only as long as is needed.
> The service/BroadcastReceiver pair needs a second WakeLock to ensure
> that everything stays awake long enough to pop the work into the work
> manager. However, this second WakeLock is then released (the "forget"
> part of "fire and forget"). This second WakeLock is a static data member
> on the service class, which, as Ms. Hackborn indicates, seems
> unavoidable in the current Android SDK. C'est la vie.
> Right now, the WakeWorkManager uses only a single background thread. If
> jobs will routinely take longer than the alarm period (e.g., slow data
> transfer), you'll probably want more than one thread. Implementation of
> this is left as an exercise for the reader.
> I am definitely up for comments, particularly if you see that I am
> screwing up WakeLocks or whatnot. Either reply on this thread or join
> the cw-android Google Group and chime in there.
> Thanks to all who contributed ideas and insights, on this thread (e.g.,
> Ms. Hackborn, Mr. Kamp) and on past threads (e.g., Jon Culverson).
Great thread, one of the best I've read here in a long time.
A few related questions -
(1) Is it recommended that a Service which runs for more than a few
seconds always use a wake lock in an attempt to ensure it completes ?
My limited tests on a G1 seem to show that a Service that runs for a
few minutes ( up to about 5 minutes ) does not seem to need a wake
lock as the phone stays awake at least until the service is completed.
I have not tried forcing the issue by turning the phone off during the
Service running.
(2) Where a Service is killed by the system in a low memory situation
and possibly restarted, is the Services onDestroy() method always
called by the system or is the Service just killed ?
If the system then restarts the Service is onStart() called again with
any of the original pending Intents or is only onCreate() called and
the Service is then responsible for working out what work is still
outstanding based on what it has previously stored about those intents
from persistent storage ?
And do these behaviors vary according to whether the Service runs in
the same process as an Activity, or in its own separate process ? ( I
am mainly asking about a Service which runs in its own process )
(3) Should the threads running in a service always be niced down or
will the system eventually do this automatically ?
> [NOTE: If you found this message in the archives and are reading it
> after June 1, 2009, please visithttp://commonsware.com/AdvAndroid/and > download the source code from the link provided there, as the code
> probably has changed]
> It needs more testing, particularly for Mr. Kamp's scenario, but I think
> it has a chance of holding up. Note that if you try building it, adjust
> default.properties to reflect your SDK location, and you'll need an SD
> card (or card image in the emulator).
> The goal behind this example is to demonstrate what a lot of people have
> been requesting: cron-style functionality. Meaning, a scheduler should
> trigger their code on a fixed interval, including from the point when
> the device boots, and should cause the code to run even if the device is
> otherwise asleep. It also attempts to handle Mr. Kamp's scenario where
> the same logic might also be invoked beyond just the scheduler, and
> where the logic might sometimes run longer than the alarm period.
> When installed, it will set up a RECEIVE_BOOT_COMPLETED
> BroadcastReceiver, which in turn will set up an AlarmManager
> ELAPSED_REALTIME_WAKEUP alarm set to recur at five minute intervals.
> The app's "purpose" is to add an entry to a running log file on the SD
> card (placed there for simplicity when testing on a device).
> The actual work to log the data to the file is done by a
> WakeWorkManager. This class manages a background thread for a service
> with automatic WakeLock management for background work. It wraps a
> LinkedBlockingQueue and, so long as there is work in the queue, keeps a
> partial WakeLock. This allows the service (and the BroadcastReceiver
> that starts the service upon an alarm) to "fire and forget" -- work will
> get done and the service will stop when everything is done, with a
> WakeLock ensuring the device will run only as long as is needed.
> The service/BroadcastReceiver pair needs a second WakeLock to ensure
> that everything stays awake long enough to pop the work into the work
> manager. However, this second WakeLock is then released (the "forget"
> part of "fire and forget"). This second WakeLock is a static data member
> on the service class, which, as Ms. Hackborn indicates, seems
> unavoidable in the current Android SDK. C'est la vie.
> Right now, the WakeWorkManager uses only a single background thread. If
> jobs will routinely take longer than the alarm period (e.g., slow data
> transfer), you'll probably want more than one thread. Implementation of
> this is left as an exercise for the reader.
> I am definitely up for comments, particularly if you see that I am
> screwing up WakeLocks or whatnot. Either reply on this thread or join
> the cw-android Google Group and chime in there.
> Thanks to all who contributed ideas and insights, on this thread (e.g.,
> Ms. Hackborn, Mr. Kamp) and on past threads (e.g., Jon Culverson).
On Sun, Mar 29, 2009 at 5:58 PM, gjs <garyjamessi...@gmail.com> wrote: > (1) Is it recommended that a Service which runs for more than a few > seconds always use a wake lock in an attempt to ensure it completes ?
It's not really a matter of how long you run. If you want to run at all, and don't know that the screen will be on while doing do, then you need to hold a wake lock.
> My limited tests on a G1 seem to show that a Service that runs for a > few minutes ( up to about 5 minutes ) does not seem to need a wake > lock as the phone stays awake at least until the service is completed. > I have not tried forcing the issue by turning the phone off during the > Service running.
This is just happen-stance. There is no minimum amount of time that the system keeps the CPU running for your service to run; the CPU will only run while someone is holding a wake lock.
> (2) Where a Service is killed by the system in a low memory situation > and possibly restarted, is the Services onDestroy() method always > called by the system or is the Service just killed ?
No, nothing is called. You will usually get onLowMemory() though.
> If the system then restarts the Service is onStart() called again with > any of the original pending Intents or is only onCreate() called and > the Service is then responsible for working out what work is still > outstanding based on what it has previously stored about those intents > from persistent storage ?
Only onCreate() is guaranteed to be called. The onStart() method will only be called if there are outstanding startService() requests that you have not seen.
> And do these behaviors vary according to whether the Service runs in > the same process as an Activity, or in its own separate process ? ( I > am mainly asking about a Service which runs in its own process )
The rules are outlined in the docs, and there is nothing special about having one thing run in one place or another... except whether the process will be killed is determined by the most import thing in that process.
> (3) Should the threads running in a service always be niced down or > will the system eventually do this automatically ?
You should do this. Use Process.setThreadPriority(); there is a standard constant for background threads.
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
> On Sun, Mar 29, 2009 at 5:58 PM, gjs <garyjamessi...@gmail.com> wrote:
> > (1) Is it recommended that a Service which runs for more than a few
> > seconds always use a wake lock in an attempt to ensure it completes ?
> It's not really a matter of how long you run. If you want to run at all,
> and don't know that the screen will be on while doing do, then you need to
> hold a wake lock.
> > My limited tests on a G1 seem to show that a Service that runs for a
> > few minutes ( up to about 5 minutes ) does not seem to need a wake
> > lock as the phone stays awake at least until the service is completed.
> > I have not tried forcing the issue by turning the phone off during the
> > Service running.
> This is just happen-stance. There is no minimum amount of time that the
> system keeps the CPU running for your service to run; the CPU will only run
> while someone is holding a wake lock.
> > (2) Where a Service is killed by the system in a low memory situation
> > and possibly restarted, is the Services onDestroy() method always
> > called by the system or is the Service just killed ?
> No, nothing is called. You will usually get onLowMemory() though.
> > If the system then restarts the Service is onStart() called again with
> > any of the original pending Intents or is only onCreate() called and
> > the Service is then responsible for working out what work is still
> > outstanding based on what it has previously stored about those intents
> > from persistent storage ?
> Only onCreate() is guaranteed to be called. The onStart() method will only
> be called if there are outstanding startService() requests that you have not
> seen.
> > And do these behaviors vary according to whether the Service runs in
> > the same process as an Activity, or in its own separate process ? ( I
> > am mainly asking about a Service which runs in its own process )
> The rules are outlined in the docs, and there is nothing special about
> having one thing run in one place or another... except whether the process
> will be killed is determined by the most import thing in that process.
> > (3) Should the threads running in a service always be niced down or
> > will the system eventually do this automatically ?
> You should do this. Use Process.setThreadPriority(); there is a standard
> constant for background threads.
> Note: please don't send private questions to me, as I don't have time to
> provide private support. All such questions should be posted on public
> forums, where I and others can see and answer them.
