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. Motorola Droid 3 unit (BNIB, Batangan 99%, Batangan 90%), HTC Droid Eris Batangan 99%

Numpang iklan barang barusan masuk:

1. Motorola Droid BNIB.
2. Motorola Droid Batangan mulus sekali 99% tanpa cacat like new. HP
Charger saja.
3. Motorola Droid Batangan 90%, HP Charger saja.
4. HTC Droid Eris Mulus sekali 99% like new.

1. semua item unlocked, siap inject.
2. Semua Motorola Droid sudah terinject smart nomor baru. tinggal
pakai saja. EVDO.
3. Droid Eris bisa diinject sesuai keinginan buyer.
4. Contact detail:

email/japri/ym:, kalau japri kesini
bukannya ga mau bales, tp ga keliatan ketimbun email milis.
telp 081510377899. no sms thx.
COD Cideng Jakarta Pusat.

"Indonesian Android Community [id-android]" 

2. User thread to update UI but still come after, can anyone look at this code and help me?

Hello Mystique,

When this code starts the thread, it then goes straight back to
execute DoSomeTask() while the thread is running, and so most of the
time the dialog will be shown after DoSomeTask.

Maybe you meant to do something like this:

   ProgressDialog dialog;

  final Runnable runInUIThread = new Runnable()  {
       public void run() {

  public void onClick(View v) {
          // TODO Auto-generated method stub

          dialog = new ProgressDialog(CloseVault.this);
          dialog.setMessage("Please wait...");

          Thread myTask = new Thread() {
                        public void run() {

You are right, though, ASyncTask is a nicer way of doing it.


3. Repost WTS: Motorola Droid 2nd + Bonus :))

4. Need help in compile android source under ubuntu 10.04

5. jam sering keganti

6. User thread to update UI but still come after, can anyone look at this code and help me?

7. Flash On Spica