Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

START_STICKY, foreground Android service goes away without notice

I have started a service in my new application. The service is foregrounded, with a Notification. When this is run in the AVD 2.1 API Level 7, all works fine. But when it's run on a Samsung Galaxy Tab running Gingerbread, the service will start (the icon and app name appear at the top of the notification area), but after a few seconds, the service disappears. The last entry in the Log that I can see is associated with my App, is the result of my Log.d("Taglines","Returning with " + START_STICKY), which immediately precedes "return START_STICKY ;" in my Service's onStartCommand override, as follows:

@Override
public int onStartCommand(Intent intent, int flags, int startId) {

    int rc ;
    Log.d("Taglines","onStartCommand()");
    Toast.makeText(this, "Starting service TagsManager", Toast.LENGTH_SHORT).show();
    Log.d("Taglines","Calling super.onStartCommand()");
    rc = super.onStartCommand(intent,flags,startId);
    Log.d("Taglines","super.onStartCommand return code was " + rc);
    createNotification(INITIAL_NOTIFICATION_TEXT);
    Log.d("Taglines","Returning with " + START_STICKY);
    return START_STICKY ;
}

The notification is set like this:

void createNotification(String text) {

    Log.d("Taglines","createNotification called");
    if (mNotificationManager == null) {
        // Get a reference to the Notification Manager
        String ns = Context.NOTIFICATION_SERVICE;
        mNotificationManager = (NotificationManager) getSystemService(ns);
        Log.d("Taglines","Obtained reference to Notification Manager");
    }

    // Instantiate the Notification
    int icon = R.drawable.ic_notification;
    CharSequence tickerText = "Taglines";
    long when = System.currentTimeMillis();

    notification = new Notification(icon, tickerText, when);

    // Define Notification's expanded message and intent
    Log.d("Taglines","createNotificacion() .. getApplicationContext");
    context = getApplicationContext();
    contentText = text;
    // notificationIntent = new Intent(this, TagsOverview.class);
    notificationIntent = new Intent(this, TagsServiceMenu.class);
    contentIntent = PendingIntent.getActivity(this, 0, notificationIntent, 0);

    notification.setLatestEventInfo(context, contentTitle, contentText, contentIntent);

    // Pass the Notification to the NotificationManager: 
    Log.d("Taglines","createNotificacion() ... passing notification");
    mNotificationManager.notify(NOTIFICATION_ID, notification);
    Log.d("Taglines","Starting foreground");
    startForeground(NOTIFICATION_ID, notification);
    Log.d("Taglines","Started");
}

This is the result from "adb logcat" when the service is started:

D/Taglines(21863): Starting service
D/Taglines(21863): TagsManager(nullary) completed
D/Taglines(21863): onStartCommand()
D/Taglines(21863): Calling super.onStartCommand()
D/Taglines(21863): super.onStartCommand eturn code was 2
D/Taglines(21863): createNotification called
D/Taglines(21863): Obtained reference to Notification Manager
D/Taglines(21863): createNotificacion() .. getApplicationContext
D/Taglines(21863): createNotificacion() ... passing notification
D/Taglines(21863): Starting foreground
D/Taglines(21863): Started
D/Taglines(21863): Returning with 1

After that, nothing special (nothing at all from PID 21863). Just a bunch of:

D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
W/InputManagerService(  302): Window already focused, ignoring focus gain of:         com.android.internal.view.IInputMethodClient$Stub$Proxy@40bc06e8
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false
D/KeyguardViewMediator(  302): setHidden false

I don't think it's needed in this case, but here's the relevant portion of the AndroidManifest.xml:

    <service android:name=".TagsManager"
             android:exported="false">
    </service>

Where might I have gone wrong? What other information can I provide?

like image 539
Dennis Avatar asked Jul 08 '11 01:07

Dennis


People also ask

What is a foreground notification?

Foreground services show a status bar notification, so that users are actively aware that your app is performing a task in the foreground and is consuming system resources. Devices that run Android 12 (API level 31) or higher provide a streamlined experience for short-running foreground services.

What is a sticky service?

Sticky Services — Sticky service is somewhere between regular service and foreground service Android will kill the process time to time of this service, however it will be created automatically if the resources are available as soon as possible.

What is sticky and non sticky in Android?

START_STICKY. the system will try to re-create your service after it is killed. START_NOT_STICKY. the system will not try to re-create your service after it is killed. Standard example: @Override public int onStartCommand(Intent intent, int flags, int startId) { return START_STICKY; }


2 Answers

A few things:

  1. Get rid of the mNotificationManager.notify(NOTIFICATION_ID, notification);. startForeground() displays the notification icon for you.

  2. Foreground Services can still be killed, they're just less likely to be.

  3. There's a bug in 2.3 (not sure if it was fixed yet) where when a Service is killed and restarted, its onStartCommand() will NOT be called again. Instead you're going to have to do any setting up in onCreate().

like image 184
Kevin TeslaCoil Avatar answered Nov 02 '22 22:11

Kevin TeslaCoil


Both codes are only relevant when the phone runs out of memory and kills the Service before it finishes executing. START_STICKY tells the OS to recreate the service after it has enough memory and call onStartCommand() again with a null intent. START_NOT_STICKY tells the OS to not bother recreating the service again. There is also a third code START_REDELIVER_INTENT that tells the OS to recreate the Service AND redelivery the same intent to onStartCommand().

This article by Dianne Hackborn explained the background of this a lot better then the official documentation.

The key part here is a new result code returned by the function, telling the system what it should do with the service if its process is killed while it is running:

START_STICKY is basically the same as the previous behavior, where the service is left "started" and will later be restarted by the system. The only difference from previous versions of the platform is that it if it gets restarted because its process is killed, onStartCommand() will be called on the next instance of the service with a null Intent instead of not being called at all. Services that use this mode should always check for this case and deal with it appropriately.

START_NOT_STICKY says that, after returning from onStartCreated(), if the process is killed with no remaining start commands to deliver, then the service will be stopped instead of restarted. This makes a lot more sense for services that are intended to only run while executing commands sent to them. For example, a service may be started every 15 minutes from an alarm to poll some network state. If it gets killed while doing that work, it would be best to just let it be stopped and get started the next time the alarm fires.

START_REDELIVER_INTENT is like START_NOT_STICKY, except if the service's process is killed before it calls stopSelf() for a given intent, that intent will be re-delivered to it until it completes (unless after some number of more tries it still can't complete, at which point the system gives up). This is useful for services that are receiving commands of work to do, and want to make sure they do eventually complete the work for each command sent.

like image 40
Sazzad Hissain Khan Avatar answered Nov 02 '22 23:11

Sazzad Hissain Khan