0

I am using an empty activity to start a sticky service. I start the service using the following code.

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    Intent service = new Intent(this, MyService.class);
    service.setAction("com.company.test.MyService");
    startService(service);
    finish();
    setContentView(R.layout.activity_transparent);
}

The problem is that if the activity gets killed it will cause the service to restart. Is there a way to avoid this problem?

Note: I am killing the application by swiping it out of the task manager, and not the activity's finish() call.

vipluv
  • 607
  • 5
  • 8
kechap
  • 2,077
  • 6
  • 28
  • 50
  • 1
    If the Activity is killed by the system it means the whole process was killed, so the question is moot. – Steve M Jan 30 '15 at 18:43
  • 1
    How do you know the service is being restarted? This call to `finish()` should not have any effect on the service. – Larry Schiefer Jan 30 '15 at 18:43
  • 1
    `finish()` doesn't kill the service, if you kill the activity from the task manager it will kill your service too. This can also happen in some cases if your activity goes on pause. – kechap Jan 30 '15 at 18:47
  • 1
    and why call `setContentView(R.layout.activity_transparent);` after `finish();`? does buying clothes for a 3 sec late dead dog make sensee?? – Elltz Jan 30 '15 at 19:39
  • 2
    @Elltz Maybe in another life the dog will need the clothes. – kechap Jan 30 '15 at 19:43
  • 1
    Reminder: Services run within the application process. http://developer.android.com/reference/android/app/Service.html – Jim Rush Jan 30 '15 at 20:38

1 Answers1

1

No, actually. This is a new feature in the Android SDK- killing the app kills all processes connected to the app, and even the app's sticky services will not restart anymore.(EDIT: The service may not restart, depending on the device; apparently sticky services are still a buggy feature on certain versions of android.)

If you want to keep your service perpetually running, you will need to use a ForegroundService, with a persistent notification in the drawer.

Apparently, this is to make sure that no services run without the user's knowledge.

vipluv
  • 607
  • 5
  • 8
  • So can I use `setForeground` inside the `onStartCommand` and also `return START_STICKY` cause I think it is the same thing. – kechap Jan 30 '15 at 19:05
  • Actually, you need to use startForeground; setForeground is deprecated. Look at this answer: http://stackoverflow.com/questions/5647815/can-anyone-explain-the-service-setforeground-method – vipluv Jan 30 '15 at 19:15
  • A foreground service has a permanent notification and icon displayed so the user is aware of its existence and hence the os won't kill it. START_STICKY, on the other hand, just makes sure the service restarts if it is killed by the os- that too only if your app's process is still alive. – vipluv Jan 30 '15 at 19:16
  • The foreground service, basically, runs in its own process, while a background service, even if it is sticky, runs within the app's process. – vipluv Jan 30 '15 at 19:18
  • @vipluv where do you see information about this being a new feature of the SDK? Android is built so Activities, Services, BroadcastReceiver and ContentProviders have separate lifecycles. A call to `finish()` in an `Activity` will have no bearing on the life of a `Service`. The system has always (by default) used the same process for these components and if the process is killed they are all killed; but it is not the same thing as calling `finish()`. – Larry Schiefer Jan 30 '15 at 20:08
  • @LarrySchiefer, he doesn't mean the finish() call killing his service, he means it gets killed when he swipes out his app, for example. Also, earlier sticky services would be restarted by the system even if the app was swiped out; this does not happen anymore. See http://stackoverflow.com/questions/18612880/android-service-crashes-after-app-is-swiped-out-of-the-recent-apps-list, mainly Locutus' comment on the answer. :-) – vipluv Jan 30 '15 at 20:18
  • Fair enough, that makes more sense. Thanks for clarifying. The original post was not clear that the task manager was being used to kill off the activity, only that the code was calling `finish()`. – Larry Schiefer Jan 30 '15 at 20:21
  • @vipluv I don't think a foreground service runs it's own process by default, what is the evidence of this? Only time you get a new process is if you use android:process in manifest. – Steve M Jan 30 '15 at 20:30
  • @vipluv: Testing on KitKat 4.4.4 and Lollipop 5.0.0, sticky background services are always restarted after being killed due to task removal. – corsair992 Jan 31 '15 at 15:06
  • @corsair992 https://code.google.com/p/android/issues/detail?id=63793 I'm sorry, apparently this is a bug that appears on certain devices only and may or may not have been fixed. I made a faulty assumption. My bad. – vipluv Feb 02 '15 at 07:13
  • @vipluv: It looks like it was introduced in the initial version of KitKat, then fixed in 4.4.3. – corsair992 Feb 02 '15 at 07:19