Keeping service alive across configuration changes

by THill » Thu, 08 Apr 2010 07:45:05 GMT

Sponsored Links
 The default way configuration changes (i.e., rotates) are handled is
to destroy the activity & recreate it with a new one.  What is the
recommended way to handle these changes in an activity that binds/
unbinds to a service (that is possibly heavy/slow to start)?

When the activity gets destroyed, it unbinds & causes the service to
be destroyed.  When the new activity is created, it binds & recreates
the service.

The only choices seem to be:
-- override onConfigurationChanged in the activity.  Feels ok, but non-
-- explicitly start the service & only stop it when the last activity
gets an onDestroy that's not due to a config change (i.e., there was
no call to onRetainNonConfigurationInstance).  Feels icky.
-- explicitly start the service & don't stop it until some amount of
time after the last unbind.  Ickier.

On a related note, what happens between activity switches within a
process, where the first activity (A) starts the next activity (B) &
then calls finish() -- is there a guarantee that B.onCreate is called
before A.onDestroy?  If not, and the activities share a service, the
same issue of keeping the service alive during this window exists, but
with only the icky workarounds.




Keeping service alive across configuration changes

by Dianne Hackborn » Thu, 08 Apr 2010 08:17:46 GMT

 You can use the ApplicationContext to bind to the service, and propagate the
binding to the next instance via

Yeah, sorry, obtuse and awkward.  In the future I'd like to have something


Sponsored Links

Keeping service alive across configuration changes

by THill » Thu, 08 Apr 2010 10:44:10 GMT

 Thanks Dianne, I was wondering if there was a way to preserve that

If I go with that approach, I guess the ServiceConnection object will
have to be static or belong to the Application also.

What about the other scenario, where one activity launches another &
then calls finish().  Is onCreate of the second activity guaranteed to
be called before onDestroy of the first?  If not, the service could go
away in that window.


> >

Keeping service alive across configuration changes

by Bob Kerns » Thu, 08 Apr 2010 20:36:33 GMT

 Another approach, which may have benefits beyond the configuration
change issue, is to make your service only tear down the expensive
resource after a delay. Then, if you reconnect before that timeout,
you can simply reuse the resource. So if you exit and come back soon
into your app, for example, you can rebind and not have to redo the
expensive initialization. If the initialization is really expensive,
this may be well worthwhile.

I suspect the best way to do this is for the first binding the service
to do a start of itself, and for the last unbind to post a delayed


Keeping service alive across configuration changes

by THill » Thu, 08 Apr 2010 23:32:47 GMT

 hank you for the replies.

Jason -- I am binding the ServiceConnection in onCreate & unbinding in
onDestroy. Don't know of a way to unbind by default.

The drawback I see with using the application context to bind the
service, is that somebody still has to own the ServiceConnection. If
it is owned by the application, or is a static member of the activity,
the activity would have to register their instance with it to be
notified of connected/disconnected events. Not terrible, but kinda
defeats the purpose of allowing activities to bind to services if the
best place to do it is really at the application level.

Bob -- I've actually done what you described in the past, but I was
never comfortable with the self-destruct timer (how long should it be,
will it vary by device/OS version, etc). Also, for a service that
plays audio, you'd want the audio to stop when the application exits,
not during configuration changes, or activity transitions. Hence then
need to prevent the last unbind, but only until the last activity has
finished. This gets even more ugly on the NexusOne, where the last
activity doesn't get onStop/onDestroy right away when the last
activity is finished -- but that's another forum posting <grin>.


On Apr 8, 5:36am, Bob Kerns <> wrote:


Keeping service alive across configuration changes

by Juhan » Thu, 13 May 2010 01:13:55 GMT

 o what solution do you use? I am facing the very same problem.

On Apr 8, 6:32pm, THill <> wrote:


Other Threads

1. Widget process lifetime: Why not stop the service?

I'm writing a widget that needs to update rather infrequently (say
multiple hours). Following the source examples out there, it seems the
common solution is to use a service to prepare the updates. However,
after I am done, my process is still running on "service level", it
looks like it's not being killed by Android in low memory conditions,
and killing it manually causes it to restart.

The same seems to be true for all other widgets I have installed so
far - they stay in memory.

Wouldn't it be better to have to service call this.stop() when it is
done, at least if the widget knows it probably won't need to do
another update any time soon?

I'm doing this now, and it seem to work fine - my process is being
killed when Android needs memory. I'm confused though as to why this
wouldn't be the encouraged behaviour then (it's not like the G1 has an
aweful lot of memory to spare). Should or shouldn't I be doing this?

2. Main and three binder threads are running after application close

This is the intended behavior.  See the docs starting here:

 http://www.***.com/ #procthread

Dianne Hackborn
Android framework engineer

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.


3. How to cancle a dialog when touch it?

4. Intent Selected_alternative

5. Docs: AsyncTask

6. AsyncTask posting mulitple parameters

7. Simplistic instructions from Spinner Selection to a Linear Image View?