Observation and comments on Android and "regularly" scheduled events

Showing 1-22 of 22 messages
Observation and comments on Android and "regularly" scheduled events bc 3/27/09 8:06 AM
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.

Re: [android-developers] Observation and comments on Android and "regularly" scheduled events Mark Murphy 3/27/09 8:18 AM
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!

Re: Observation and comments on Android and "regularly" scheduled events bc 3/27/09 9:24 AM
Hi Mark,

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
Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Mark Murphy 3/27/09 9:45 AM
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.

--
Mark Murphy (a Commons Guy)
http://commonsware.com
Android App Developer Training: http://commonsware.com/training.html

Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Mariano Kamp 3/27/09 10:10 AM
Hard to judge without any code.

Do you use AlarmManager.RTC_WAKEUP?
Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Dianne Hackborn 3/27/09 11:34 AM
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.--
Dianne Hackborn
Android framework engineer
hac...@android.com

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.

Re: Observation and comments on Android and "regularly" scheduled events bc 3/27/09 2:14 PM
Dianne,

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);

// Schedule the alarm!
long firstTime = SystemClock.elapsedRealtime();
AlarmManager objAlarmManager = (AlarmManager)getSystemService
(ALARM_SERVICE);
objAlarmManager.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
firstTime, 5*60*1000, objPendingIntent);


in the service

@Override
public void onCreate()
{
        super.onCreate();

        Thread objThread = new Thread(null, doTasks, "bService");
        objThread.start();
}


private Runnable doTasks = new Runnable()
{
        public void run()
        {
                PowerManager objPowerManager = null;
                PowerManager.WakeLock objWakeLock = null;

                try
                {

                        objPowerManager = (PowerManager) getSystemService
(Context.POWER_SERVICE);
                        //objWakeLock = objPowerManager.newWakeLock
(PowerManager.FULL_WAKE_LOCK, "bService_Class");
                        objWakeLock = objPowerManager.newWakeLock
(PowerManager.PARTIAL_WAKE_LOCK, "bService_Class");
                        objWakeLock.acquire();

                        //Your processing tasks here.
                }
                catch (Exception e)
                {
                }
                finally
                {
                        try
                        {
                                objWakeLock.release();
                        }
                        catch (Exception e1)
                        {
                        }
                }

                bService.this.stopSelf();
        }
};

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:
> hack...@android.com
>
> 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 -
>
> - Show quoted text -
Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Dianne Hackborn 3/27/09 2:54 PM
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.hac...@android.com
Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Mark Murphy 3/27/09 5:03 PM
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!

Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Dianne Hackborn 3/27/09 6:53 PM
On Fri, Mar 27, 2009 at 5:03 PM, Mark Murphy <mmu...@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.

Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Mariano Kamp 3/28/09 1:44 AM
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.
Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Mark Murphy 3/28/09 4:48 AM
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.

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

_The Busy Coder's Guide to Android Development_ Version 2.0 Available!

Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Mariano Kamp 3/28/09 8:06 AM
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
Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Mark Murphy 3/28/09 8:37 AM
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. ;-)

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

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

Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Mariano Kamp 3/28/09 9:10 AM
On Sat, Mar 28, 2009 at 4:37 PM, Mark Murphy <mmu...@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.
Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Mark Murphy 3/28/09 9:17 AM
Mariano Kamp wrote:
> On Sat, Mar 28, 2009 at 4:37 PM, Mark Murphy <mmu...@commonsware.com

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...

;-)

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

_The Busy Coder's Guide to Android Development_ Version 2.0 Available!

Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Dianne Hackborn 3/28/09 10:34 AM
Sorry this is currently such a pain.

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.
Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Mark Murphy 3/28/09 12:46 PM
Dianne Hackborn wrote:
> Yes you need to use a global variable for the wake lock.  Gross, but it
> works.

OK, here's a cut at a sample app:

http://groups.google.com/group/cw-android/web/Alarm.zip

[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).

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

_The Busy Coder's Guide to Android Development_ Version 2.0 Available!

Re: Observation and comments on Android and "regularly" scheduled events bc 3/29/09 4:43 PM
Dianne and Mark,

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!!!
> Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy
Re: Observation and comments on Android and "regularly" scheduled events gjs 3/29/09 5:58 PM
Hi,

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 ?

This was mentioned here
http://groups.google.com/group/android-developers/browse_thread/thread/1952712754139019/bd8eb716be2d4915

Thanks

Regards
> Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy
Re: [android-developers] Re: Observation and comments on Android and "regularly" scheduled events Dianne Hackborn 3/30/09 2:09 AM
On Sun, Mar 29, 2009 at 5:58 PM, gjs <garyjam...@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.

Re: Observation and comments on Android and "regularly" scheduled events Marco P. 4/3/09 12:26 AM
So, given that the functionality should be there,
why is the AlarmClock App (from Google!) not working yet?
http://code.google.com/p/android/issues/detail?id=1942

Is that a bug in the application, in the system, in the hardware or
something else?

Thanks
M

On Mar 30, 11:09 am, Dianne Hackborn <hack...@android.com> wrote:
> hack...@android.com
More topics »