Alarm is canceled if app is stopped

1357 views
Skip to first unread message

Lazarus 101

unread,
Oct 12, 2009, 4:00:15 PM10/12/09
to Android Developers
I have an app that does some polling every 2 hours. I set a repeating
alarm that starts a service but I have noticed that if I use some task
manager (e.g. TasKiller) to kill my app then the polling will not be
performed from that moment on. I know this because I store the time of
the last poll, I have also checked the server logs and there are no
requests received from the client after I force close my app.
Is this the way alarms work or should I look somewhere else for a
crash or smth? because if alarms really get canceled then how should
we implement the polling?

I'm also interested in what happens with a running service if it gets
killed from another app (I assume all task managers are using
ActivityManager.restartPackage() to kill other apps), does it get
restarted?

Dianne Hackborn

unread,
Oct 12, 2009, 4:22:27 PM10/12/09
to android-d...@googlegroups.com
That is intentional.  Stopping an application is there for the user to stop everything associated with it -- processes, alarms, services, notifications, etc.  They will not be restarted until someone explicitly does so (typically this would be the user re-launching the app and having it do the appropriate thing).

It sounds like TasKiller is abusing this API.  The API is there for the user to explicitly stop an app from running without going to the most extreme measure of uninstalling the app.  Trying to use it to automatically stop things behind the user's back seems...  questionable, and probably not what the user actually wants.
--
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, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

Lazarus 101

unread,
Oct 12, 2009, 7:09:34 PM10/12/09
to Android Developers
Thanks Dianne for the quick answer.

Actually TasKiller is not automatically killing apps, but it has a
widget that allows users to kill (almost) all apps with one click.
Most of the Android users that I know are using something similar to
TasKiller so this is a tricky problem, users will blame my app for not
doing what it says it does.
I saw there is a PACKAGE_RESTARTED broadcast but obviously the
restarted package does not receive the notification so there's not
much I can do to "fix" this problem...

Having applications that can affect the functionality of every other
apps installed on the system is not such a good idea IMHO. A Task
Manager is needed but the user should be clearly informed that the
apps he choses to kill are not working anymore because that's exactly
what he wanted. Also the permission is called "restart other
application" it should be "kill other applications", that's why I
thought alarms are not affected by this and that services are getting
restarted (I saw services being restarted after crashes or after being
killed due to lack of memory so I though it's the same behaviour when
calling ActivityManager.restartPackage).
> hack...@android.com

Dianne Hackborn

unread,
Oct 12, 2009, 7:12:41 PM10/12/09
to android-d...@googlegroups.com
*sigh* I knew I shouldn't have made that API public. :}
hac...@android.com

Nicolas Thibaut

unread,
Oct 13, 2009, 11:50:10 AM10/13/09
to Android Developers
:)
I am the taskiller developper.

If an user choose to kill your app. Your app may not be restarted.

Users are using taskiller because too more apps have bad implemention
of broadcasters.
Too many apps are launching without user action, like uninstalled
widgets, because they receive
Broadcast and dont verify the effective use of the app.
Too many apps are implementing Start on boot when not needed.

With taskiller, users are checking that too many apps are loaded on
startup and 50% of these apps are not useful at startup....(like
meeboo,facebook,.. )

Too many apps are not explaining what they do. If your apps are using
background service, inform the user that the app will stay
in background, and maybe the users will not kill "stupidly" your app.

And the bad news is that others task managers are implementing
autokill.... or Boot kill....which can made many apps crashing (if
your app use an intents to another app...if this app is autokilled
your app will never worl :( ...


On Oct 13, 1:09 am, Lazarus 101 <lazarus...@gmail.com> wrote:
> Thanks Dianne for the quick answer.
>
> ActuallyTasKilleris not automatically killing apps, but it has a
> widget that allows users to kill (almost) all apps with one click.
> Most of the Android users that I know are using something similar toTasKillerso this is a tricky problem, users will blame my app for not
> doing what it says it does.
> I saw there is a PACKAGE_RESTARTED broadcast but obviously the
> restarted package does not receive the notification so there's not
> much I can do to "fix" this problem...
>
> Having applications that can affect the functionality of every other
> apps installed on the system is not such a good idea IMHO. A Task
> Manager is needed but the user should be clearly informed that the
> apps he choses to kill are not working anymore because that's exactly
> what he wanted. Also the permission is called "restart other
> application" it should be "kill other applications", that's why I
> thought alarms are not affected by this and that services are getting
> restarted (I saw services being restarted after crashes or after being
> killed due to lack of memory so I though it's the same behaviour when
> calling ActivityManager.restartPackage).
>
> On Oct 12, 11:22 pm, Dianne Hackborn <hack...@android.com> wrote:
>
>
>
> > That is intentional.  Stopping an application is there for the user to stop
> > everything associated with it -- processes, alarms, services, notifications,
> > etc.  They will not be restarted until someone explicitly does so (typically
> > this would be the user re-launching the app and having it do the appropriate
> > thing).
>
> > It sounds likeTasKilleris abusing this API.  The API is there for the user
> > to explicitly stop an app from running without going to the most extreme
> > measure of uninstalling the app.  Trying to use it to automatically stop
> > things behind the user's back seems...  questionable, and probably not what
> > the user actually wants.
>
> > On Mon, Oct 12, 2009 at 1:00 PM, Lazarus 101 <lazarus...@gmail.com> wrote:
>
> > > I have an app that does some polling every 2 hours. I set a repeating
> > >alarmthat starts a service but I have noticed that if I use some task
> > > manager (e.g.TasKiller) to kill my app then the polling will not be

String

unread,
Oct 13, 2009, 4:44:56 PM10/13/09
to Android Developers
On Oct 13, 4:50 pm, Nicolas Thibaut <nthibau...@gmail.com> wrote:

> And the bad news is that others task managers are implementing
> autokill.... or Boot kill....which can made many apps crashing (if
> your app use an intents to another app...if this app is autokilled
> your app will never worl :( ...

I'm getting complaints from users about my app stalling - it's a clock
widget, and people don't like it when the clock stops. My best guess
is that these users have "autokill" apps running, and killing my
process disables the alarm that updates my widget.

I've been able to create a workaround (with updateperiodmillis), but
it seems like something of an arms race at this point. Some apps ARE
badly behaved and launch at startup when there's no good reason for
them to, leading to the proliferation of task killers, which can then
indiscriminately kill processes which the user DOES want running, and
the affected developers move on to other workarounds. Perhaps there
should be two levels of permission relating to other apps, stop/start
processes and stop/start alarms?

String

momo

unread,
Oct 13, 2009, 4:59:50 PM10/13/09
to Android Developers
Maybe make another API call that allows killing the service,
notifications, and etc of an application except for alarms? I think
other applications are affected the most by their alarms getting
totally wiped out by another application.

Too many task killing applications are using this API call. I am sure
if a safer call is available, most of them will switch to it.

Lazarus 101

unread,
Oct 13, 2009, 7:19:08 PM10/13/09
to Android Developers
Hi Nicolas,

I'm using your app on my personal phone, but I kill apps from the Task
Bar widget, so I chose carefully which one I want to kill, but most
users are using the other widget which only displays the number of
apps running and kills all (except system apps and those on ignore
list) of them if clicked.
Well I guess the only thing I can do is warn my users about this...

EboMike

unread,
Oct 14, 2009, 12:09:19 AM10/14/09
to Android Developers
Task killers aside, what about if the OS decides to stop a process
because memory is low? Say an app has an alarm set to happen in 2
hours, and the user decides to run Google Maps for a minute. Android
might kill said app because memory runs low. Ten minutes later, the
user is back on the home screen, but the alarm is gone for good until
the user runs the app again. How would something like an alarmclock-
style app handle that?

-Mike
> hack...@android.com

Dianne Hackborn

unread,
Oct 14, 2009, 12:58:50 AM10/14/09
to android-d...@googlegroups.com
On Tue, Oct 13, 2009 at 9:09 PM, EboMike <ebo...@gmail.com> wrote:
Task killers aside, what about if the OS decides to stop a process
because memory is low?

It doesn't do what these apps are doing.  As I said, what these apps are doing (especially the ones that do this stuff behind the user's back) is abusing an API that is not intended to be used this way.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Jason B.

unread,
Oct 15, 2009, 11:34:50 AM10/15/09
to Android Developers
I know this thread is talking a lot about task management. I think
the original post was about making alarms that still occur even if the
app is closed. This is how I do it:

1) Use AlarmManager service to schedule PendingIntents in the future
(I.e. xx min from now)

2) Creat an intent/PendingIntent pair that starts. Your service when
called, and give that to AlarmManager with your polling interval.

3) If you need to save data that your service needs when it is started
so it can continue where it left off before it was destroyed, use a
preferneces file (see SharedPreferences class)

Using that approach works great for my app. That way it doesn't
matter if my app ever gets killed. The alarm will trigger in the
future and the intent will restart my service, and I just reload my
preferences file to restore some data I'm working with.

Hope that helps.

On Oct 14, 12:58 am, Dianne Hackborn <hack...@android.com> wrote:
> On Tue, Oct 13, 2009 at 9:09 PM, EboMike <ebom...@gmail.com> wrote:
> > Task killers aside, what about if the OS decides to stop a process
> > because memory is low?
>
> It doesn't do what these apps are doing.  As I said, what these apps are
> doing (especially the ones that do this stuff behind the user's back) is
> abusing an API that is not intended to be used this way.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com

String

unread,
Oct 15, 2009, 11:53:38 AM10/15/09
to Android Developers
On Oct 15, 4:34 pm, "Jason B." <jason.ba...@gmail.com> wrote:

> Using that approach works great for my app.  That way it doesn't
> matter if my app ever gets killed.  The alarm will trigger in the
> future and the intent will restart my service

I believe the point of this thread is that Task Killer apps will kill
all future alarms you had scheduled.

String

Jason B.

unread,
Oct 15, 2009, 6:55:06 PM10/15/09
to Android Developers
When I use the method above. Even after I kill my app and service with
task manager my alarms still trigger. I believe its because the
AlarmManager service has been given a pending intent that will
relaunch my service which handles the alarms.

Both alarmmanager and the pending intent are allocated outside of the
activity, so even if the application's virtual memory space is
deleted, the pending intent still exists and the alarmmanager is still
scheduled.

Sorry if I missed the theme of the post. Good luck :)

Dianne Hackborn

unread,
Oct 15, 2009, 7:07:01 PM10/15/09
to android-d...@googlegroups.com
If you kill the process, it will not impact the alarms, the same as it won't impact notifications etc.

What these programs are doing is using the API that is tended to force stop -everything- about the application: stop all services, cancel all alarms, remove all notifications, etc.  This is all working as intended, the apps are just abusing this API to cause things to happen that you probably don't want to have done.
--
Dianne Hackborn
Android framework engineer
hac...@android.com

Bo

unread,
Nov 17, 2009, 8:15:31 AM11/17/09
to Android Developers
I think it would be nice if the to-be-killed/restarted apps/services
get a chance to say what it is doing. It's normal apps/services
obligation to provide such information; it's task manager apps
obligation to collect them and present to users.

Or make it a system service (may be some dialogs) to make sure no apps/
services is killed without judgement. (sounds familiar? ^_^)

We still need such an API to be public, just make it more gentle.
> hack...@android.com

jotobjects

unread,
Nov 17, 2009, 2:36:54 PM11/17/09
to Android Developers


On Oct 15, 3:07 pm, Dianne Hackborn <hack...@android.com> wrote:
> What these programs are doing is using the API that is tended to force stop
> -everything- about the application: stop all services, cancel all alarms,
> remove all notifications, etc.  This is all working as intended, the apps
> are just abusing this API to cause things to happen that you probably don't
> want to have done.

Does that mean Jason's solution will not work when this happens?

Is there a planned fix for this so it can't happen or at least
requires an explicit dangerous permission?

Dianne Hackborn

unread,
Nov 17, 2009, 2:40:27 PM11/17/09
to android-d...@googlegroups.com
That's not the purpose of this API, which is to allow the user to force stop an application right now, immediately, I don't care what the damn app wants. :}

There is a UI in 2.0 for the user to explicitly stop any currently running services.

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



--
Dianne Hackborn
Android framework engineer
hac...@android.com

jotobjects

unread,
Nov 17, 2009, 2:41:12 PM11/17/09
to Android Developers


On Oct 13, 8:09 pm, EboMike <ebom...@gmail.com> wrote:
> Task killers aside, what about if the OS decides to stop a process
> because memory is low? Say an app has an alarm set to happen in 2
> hours, and the user decides to run Google Maps for a minute. Android
> might kill said app because memory runs low. Ten minutes later, the
> user is back on the home screen, but the alarm is gone for good until
> the user runs the app again. How would something like an alarmclock-
> style app handle that?
>
> -Mike
>
Use Jason's solution. Also if the system kills the Process the
system will later restart the Process if it had a Service running but
it is up to the service to reset its own state.

Dianne Hackborn

unread,
Nov 17, 2009, 2:43:19 PM11/17/09
to android-d...@googlegroups.com
On Tue, Nov 17, 2009 at 11:36 AM, jotobjects <jotob...@gmail.com> wrote:
On Oct 15, 3:07 pm, Dianne Hackborn <hack...@android.com> wrote:
> What these programs are doing is using the API that is tended to force stop
> -everything- about the application: stop all services, cancel all alarms,
> remove all notifications, etc.  This is all working as intended, the apps
> are just abusing this API to cause things to happen that you probably don't
> want to have done.

Does that mean Jason's solution will not work when this happens?

Sorry I don't know what Jason's solution is.
 
Is there a planned fix for this so it can't happen or at least
requires an explicit dangerous permission?

I will probably make this API a no-op, since it violates the principle of one app not being able to break another app, and has quickly become confused.  It wouldn't make sense to require a dangerous permission, because nobody would understand what that permission means and we'd still have these apps breaking other apps.

Dianne Hackborn

unread,
Nov 17, 2009, 2:44:16 PM11/17/09
to android-d...@googlegroups.com
On Tue, Nov 17, 2009 at 11:41 AM, jotobjects <jotob...@gmail.com> wrote:
 Use Jason's solution.  Also if the system kills the Process the
system will later restart the Process if it had a Service running but
it is up to the service to reset its own state.

Not when using this API, which kills -everything- about the app.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Cédric Berger

unread,
Nov 17, 2009, 3:59:30 PM11/17/09
to android-d...@googlegroups.com
On Fri, Oct 16, 2009 at 00:07, Dianne Hackborn <hac...@android.com> wrote:
> If you kill the process, it will not impact the alarms, the same as it won't
> impact notifications etc.
>
> What these programs are doing is using the API that is tended to force stop
> -everything- about the application: stop all services, cancel all alarms,
> remove all notifications, etc.  This is all working as intended, the apps
> are just abusing this API to cause things to happen that you probably don't
> want to have done.
>

Wouldn't it be better if task killer, at least by default, just kill
all processes instead of using this API that completely kill/remove
apps ?

(Though I think it would still be helpful to be able to completely
kill some applications, just that task killer have to be more explicit
in this case, and require the user to clearly ask to)

Current situation is not really user friendly. It is really hard to
understand which applications are really running, which ones are off
but will be waken up by alarms and when, ....
Especially with our restrained device resources, a good task manager
is much needed (both to report apps usage, and to be able to control
them if needed).

(And of course I truly agree that a lot of apps do use resources
needlessly -autostart with no useful reason, always running process
when they could just be triggered up on some events,...-)

Dianne Hackborn

unread,
Nov 17, 2009, 7:05:09 PM11/17/09
to android-d...@googlegroups.com
2.0 includes a UI showing you which -services- are running and the resources they are using.  This is what you really care about, not whatever random processes are being kept around by the system in case it needs them later.  (Fwiw, the worst that can happen is a bad app sits there spinning the CPU draining your battery; you'll see this in the battery usage.  As of 1.6 it can't get more than 5% or so of the CPU so it won't cause the foreground UI to slow down.)  So having a "task killer" that kills process is really not that useful -- this comes from thinking about the system like a standard desktop, but it is not.  For example, the app may have a service running, causing the process to come right back; it may have alarms scheduled, causing the process to come right back; it may be watching for broadcasts, causing it to come right back.  That is why the API to force stop an app does what it does.

2009/11/17 Cédric Berger <cedric....@gmail.com>

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

todd

unread,
Nov 17, 2009, 7:55:20 PM11/17/09
to Android Developers
Personally I would like to see this API go away. I'm finding we now
have to code around task killing applications, which shouldn't be the
case. Being a good Android citizen and following the rules, allowing
the OS to do the work it was designed to do is the way to go. Users
are confused when the app runs in the background claiming it's taking
cpu and wasting battery because it shows up in task manager lists. In
our case our bg service only watches a particular directory waiting
for new files to be added. It's not *running*, it's waiting. Users go
off and kill our app then wonder why it doesn't work any more.

My two cents.

Todd

On Oct 13, 8:58 pm, Dianne Hackborn <hack...@android.com> wrote:
> On Tue, Oct 13, 2009 at 9:09 PM, EboMike <ebom...@gmail.com> wrote:
> > Task killers aside, what about if the OS decides to stop a process
> > because memory is low?
>
> It doesn't do what these apps are doing.  As I said, what these apps are
> doing (especially the ones that do this stuff behind the user's back) is
> abusing an API that is not intended to be used this way.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com

Dianne Hackborn

unread,
Nov 17, 2009, 8:16:39 PM11/17/09
to android-d...@googlegroups.com
On Tue, Nov 17, 2009 at 4:55 PM, todd <tdonahue.sd@gmail.com> wrote:
In
our case our bg service only watches a particular directory waiting
for new files to be added. It's not *running*, it's waiting. Users go
off and kill our app then wonder why it doesn't work any more.

Are you saying you have a Service always running in the background?  If so, then you are in fact taking significant resources that impacts the user experience.  The main limitation on the device is not CPU (especially as of 1.6 we ensure that background stuff can't disrupt more important stuff), but memory.  Having a service sitting there running consumes multiple megabytes of memory, and on most existing devices there is only enough memory to have a handful of such things running at a time.

So this is the kind of thing that, indeed, a user may want to kill because the app is using resources that they want available for other things.  As of 2.0 there is a UI for them to see these running things and make them stop if they want, so there is no more need for task killers to do this kind of thing, which are also very misleading about what is actually going on and what should be done to get resources back.

You can find the Running Services UI in 2.0 under Settings -> Applications -> Running Services.  Definitely take a look at this to make sure your app isn't leaving things running when it doesn't mean to!

(Btw, the information at the bottom is pretty obscure so here is the explanation: the first number is the amount of free/cached RAM in the system; the second is the amount of RAM used by background processes that the system can freely kill for more memory and "in N" is the number of such processes; the number on the right is the amount of RAM being used by required/foreground processes and the "in N" is the number of such processes.  The list itself shows you every running service (with the icons next to them) and the gray divider bar(s) above are the process(es) being kept around by those services showing the amount of memory being used by them.)

--
Dianne Hackborn
Android framework engineer
hac...@android.com

String

unread,
Nov 17, 2009, 10:54:16 PM11/17/09
to Android Developers
On Nov 17, 7:43 pm, Dianne Hackborn <hack...@android.com> wrote:

> I will probably make this API a no-op, since it violates the principle of
> one app not being able to break another app

+1

Especially with the Running Services UI in 2.0, I'd suggest this is
the best solution.

String

jotobjects

unread,
Nov 18, 2009, 11:14:46 AM11/18/09
to Android Developers
+1 That leaves the system utility but removes the API that can be and
is being abused.

jotobjects

unread,
Nov 18, 2009, 11:27:58 AM11/18/09
to Android Developers


On Nov 17, 4:05 pm, Dianne Hackborn <hack...@android.com> wrote:
> 2.0 includes a UI showing you which -services- are running and the resources
> they are using.  This is what you really care about

Don't you care just as much about Activities that have threads running
the background?

Two more questions about all this:

Are you saying that this UI allows the user to see AND force-kill
processes and all their alarms and notifications (sorry I haven't
looked at this 2.0 feature)?

A little doubt about all this - Why worry about Services that run in
the background? Yes it uses memory but the system can kill processes
if it needs to obtain more memory (and Services should be coded to
handle that when it happens). If an App has alarms that cause it to
restart then that is the business of the App and should be allowed.
If an App is badly written and does that too much the user can make a
decision that they don't want the App. It seems like all this follows
from the platform without any task killing facility being necessary.
What am I missing?

Dianne Hackborn

unread,
Nov 18, 2009, 12:53:53 PM11/18/09
to android-d...@googlegroups.com
On Wed, Nov 18, 2009 at 8:27 AM, jotobjects <jotob...@gmail.com> wrote:
 
Don't you care just as much about Activities that have threads running
the background?

No, the system can freely kill those processes when it needs memory.  Thus this isn't the cause of the main problem, the overall system becoming slow because too much stuff is trying to run.  If it is running it will be consuming battery, and if this is not what you want you will see this in the battery usage stats as your battery goes down, and thus know what app to blame.  There also should be some improvements to the organization of these settings (manage apps and battery use) to make it easier to discover and deal with these apps.
 
Are you saying that this UI allows the user to see AND force-kill
processes and all their alarms and notifications (sorry I haven't
looked at this 2.0 feature)?

I'm not sure which UI you are talking about.  The "force stop" button that has been around since 1.5 does everything we have been talking about: killing processes, unregistering alarms, etc.  The new running services UI -only- stops a service, doesn't kill a process or anything else, because that is all that is needed to free up that process to be available to the system.
 
A little doubt about all this - Why worry about Services that run in
the background?  Yes it uses memory but the system can kill processes
if it needs to obtain more memory (and Services should be coded to
handle that when it happens).

By definition, a service running in the background does NOT want to be killed, because this is telling the system that it is actively doing stuff.  Thus if a lot of applications run services like this, we will run out of memory to have any background processes (so each time you switch apps a new process needs to be started), and eventually will start thrashing around in the services processes that all need to be running but there is not enough memory to do so.  Thus is the main failure case see in the "too many things running causing the system to slow" situation that we are all trying to address.
 
If an App has alarms that cause it to
restart then that is the business of the App and should be allowed.

Unless the user explicitly presses force stop to get the app to stop.  Ultimately the user is in charge, not the app.  The problem with the task killers is that they put the user in charge not realizing what they are actually doing.
 
If an App is badly written and does that too much the user can make a
decision that they don't want the App. It seems like all this follows
from the platform without any task killing facility being necessary.
What am I missing?

Everything above.

jotobjects

unread,
Nov 18, 2009, 3:18:33 PM11/18/09
to Android Developers

On Nov 18, 9:53 am, Dianne Hackborn <hack...@android.com> wrote:
> On Wed, Nov 18, 2009 at 8:27 AM, jotobjects <jotobje...@gmail.com> wrote:
> > Don't you care just as much about Activities that have threads running
> > the background?
>
> No, the system can freely kill those processes when it needs memory.  Thus
> this isn't the cause of the main problem, the overall system becoming slow
> because too much stuff is trying to run.

If the system is slow due to CPU contention then an Activity running
in the background would also be part of the problem. If the system is
low on memory the System can also kill Services. But I get it that
too many Services thrashing has been the bigger problem.

>  The new running services UI
> -only- stops a service, doesn't kill a process or anything else, because
> that is all that is needed to free up that process to be available to the
> system.

So applications need to be coded to restart their own Services. It's
even possible that the app's Activities are still running threads in
the background but the Services have been stopped.

Thanks for all the clarification - for the most part confirms what I
understood.

Dianne Hackborn

unread,
Nov 18, 2009, 4:03:47 PM11/18/09
to android-d...@googlegroups.com
On Wed, Nov 18, 2009 at 12:18 PM, jotobjects <jotob...@gmail.com> wrote:
If the system is slow due to CPU contention then an Activity running
in the background would also be part of the problem.  If the system is
low on memory the System can also kill Services.  But I get it that
too many Services thrashing has been the bigger problem.

Again: as of 1.6, this will not happen, because background processes are put in a scheduling class that only allows all processes, together, to get no more than 5% or so of the CPU.
 
>  The new running services UI
> -only- stops a service, doesn't kill a process or anything else, because
> that is all that is needed to free up that process to be available to the
> system.
So applications need to be coded to restart their own Services.  It's
even possible that the app's Activities are still running threads in
the background but the Services have been stopped.

If the user has decided that your application's service(s) are not desired, they get to stop them.  You should probably consider how to recover from this.  Implementing your app so it starts a service at boot and leaves it running forever is much more likely to get you in this situation, because this is the kind of thing that cause the system to start thrashing, and your service is going to be an obvious target for people wanting to stop things.  And IMHO this is as it should be.

As far as activities running threads -- as always, if your activity creates threads, and then goes in the background, be prepared to have your process killed at any time while they are running.  If you have work to do that you want to have a better chance of keeping around, associate it with a service.  Then of course the user may decide to stop the service, at which point you will get onDestroy() called.

Cédric Berger

unread,
Nov 18, 2009, 4:24:59 PM11/18/09
to android-d...@googlegroups.com
On Wed, Nov 18, 2009 at 18:53, Dianne Hackborn <hac...@android.com> wrote:

> I'm not sure which UI you are talking about.  The "force stop" button that
> has been around since 1.5 does everything we have been talking about:
> killing processes, unregistering alarms, etc.  The new running services UI
> -only- stops a service, doesn't kill a process or anything else, because
> that is all that is needed to free up that process to be available to the
> system.
>

So now that (I think) I understand what this "force stop" is really
about (completely and definitely stopping an app) :

Are there situations where it is done by the system (automatically) ?
(ie. in case it is too low on memory).
Or can I be sure that when it is the system that kills Services, it
never does anything else (such as unregistering alarms) ? And in this
case, will such a stopped service be restarted automatically, or only
if it took care of such a situation (by ex. with a "watchdog" alarm
which will eventually restart it if stopped).

Dianne Hackborn

unread,
Nov 18, 2009, 4:45:56 PM11/18/09
to android-d...@googlegroups.com
2009/11/18 Cédric Berger <cedric....@gmail.com>
So now that (I think) I understand what this "force stop" is really
about (completely and definitely stopping an app) :

Are there situations where it is done by the system (automatically) ?
(ie. in case it is too low on memory).

Nope, definitely never ever.  The user must explicitly request this.
 
Or can I be sure that when it is the system that kills Services, it
never does anything else (such as unregistering alarms) ?

By definition it does everything described: kill all processes, stop all services, unregister all alarms, remove all notifications.  And possibly more, too.
 
And in this
case, will such a stopped service be restarted automatically, or only
if it took care of such a situation (by ex. with a "watchdog" alarm
which will eventually restart it if stopped).

No, it is intended for the user to make an app stop.  The services with not be restarted; they are stopped.

Cédric Berger

unread,
Nov 18, 2009, 4:55:55 PM11/18/09
to android-d...@googlegroups.com
On Wed, Nov 18, 2009 at 22:45, Dianne Hackborn <hac...@android.com> wrote:
> 2009/11/18 Cédric Berger <cedric....@gmail.com>

>> Are there situations where it is done by the system (automatically) ?
>> (ie. in case it is too low on memory).
>
> Nope, definitely never ever.  The user must explicitly request this.
>
>>
>> Or can I be sure that when it is the system that kills Services, it
>> never does anything else (such as unregistering alarms) ?
>
> By definition it does everything described: kill all processes, stop all
> services, unregister all alarms, remove all notifications.  And possibly
> more, too.
>

I meant not when the user requested it, but when the system went
really too low on memory : as I understand the system may eventually
have to kill some services (even if it is not a full "force stop") ?
(And if not, what happens when it is really too short on memory ?)

jotobjects

unread,
Nov 18, 2009, 5:59:30 PM11/18/09
to Android Developers


On Nov 18, 1:55 pm, Cédric Berger <cedric.berge...@gmail.com> wrote:

> I meant not when the user requested it, but when the system went
> really too low on memory : as I understand the system  may eventually
> have to kill some services (even if it is not a full "force stop") ?
> (And if not, what happens when it is really too short on memory ?)

According to the API docs for android.app.Service (under Lifecycle)
the System can kill the Process that the Service is running in (and
thus the Service of course) on low memory conditions, but Services are
given a high priority to not be killed in this way and when it happens
the System "will later try to restart the service". So that says the
System does NOT automatically stop Services per se, only processes.

My understanding (might be wrong) from earlier in this thread is that
Services can be restarted by alarms or by the system and this pressure
of too many Services trying to run is the source of the "thrashing"
that a user can resolve by using the new 2.0 stop-service UI since
then the system will NOT try to restart it (but an alarm might still
restart the service which might tick off the user who explicity
stopped it). Also (I guess) a BroadcastReciever could be agressive
about restarting the Service when it receives a broadcast.

Interesting to see how all this plays with non-technically savvy users
who (we hope) will eventually be the vast predominance of Android
users. Are they going to understand what to make of techy lists of
applications and services and how much RAM is in use, etc. Or just
throw up their hands and blame the system?
Reply all
Reply to author
Forward
0 new messages