0

I read a lot of articles on forums, but wasn't able to make the "unkillable" background service work. I tried disabling the battery optimalization ( didn't work), making the foreground service ( since making app from api 24-31, didn't find solution on how to make it work, maybe the right way to do it), making the broadcast receiver - "restarter". (Of course this isn't all, but it is everything that has something to do with the service)

Manifest:

        <service android:name="PathToService" android:foregroundServiceType="dataSync|location" />

        <receiver
            android:enabled="true"
            android:name="PathToReciever"
            android:label="RestartServiceWhenStopped">
        </receiver>

Receiver:

    @Override
    public void onReceive(Context context, Intent intent) {
        context.startService(new Intent(context, SERVICE));
    }

Service:

    @Override
    public void onDestroy() {

        Intent broadcastIntent = new Intent(this, SERVICE);
        sendBroadcast(broadcastIntent);

    }
  • I'm in middle of dealing with this too in my application so I have question if you don't mind answering, did you notice when it gets terminated ? I want to know that because while testing my app didn't notice that it got killed on any of my attempts so If you did find a way to get it killed I want to know so I could test that in my application – Omar Shawky Sep 13 '21 at 18:14
  • @OmarShawky I'm sorry, but i am not the one who is doing the testing so i dont know when exactly, it is getting terminated. ( but if you come across something let me know pls ) – adam zverina Sep 13 '21 at 18:30

1 Answers1

0

incase if your whole problem is that the OS just randomly destroys the service after a while, you could returning START_STICKY in the onStartCommand method in the foreground service

according to Android Developers documentation :

START_STICKY

If the system kills the service after onStartCommand() returns, recreate the service and call onStartCommand(), but do not redeliver the last intent. Instead, the system calls onStartCommand() with a null intent unless there are pending intents to start the service. In that case, those intents are delivered. This is suitable for media players (or similar services) that are not executing commands but are running indefinitely and waiting for a job.

if that's the case then it gets solved by this code :

@Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        super.onStartCommand(intent, flags, startId);
        ... \\ whatever your code contains here
        return START_STICKY;
    }

maybe that's why I'm telling you that I didn't notice that anything is killing my service rather during my tests.

N.B : take care that the lifetime of foreground services is higher than background ones, as since api 28 there's some restrictions on background services that might make it quite unusable for long work assignment that you should consider either switching to foreground services or use long-running-workers.

Foreground service

A foreground service performs some operation that is noticeable to the user. For example, an audio app would use a foreground service to play an audio track. Foreground services must display a Notification. Foreground services continue running even when the user isn't interacting with the app.

When you use a foreground service, you must display a notification so that users are actively aware that the service is running. This notification cannot be dismissed unless the service is either stopped or removed from the foreground.

Background

A background service performs an operation that isn't directly noticed by the user. For example, if an app used a service to compact its storage, that would usually be a background service.

Note: If your app targets API level 26 or higher, the system imposes restrictions on running background services when the app itself isn't in the foreground. In most situations, for example, you shouldn't access location information from the background. Instead, schedule tasks using WorkManager.

you can also check that question and its answer for more clarity

Omar Shawky
  • 1,242
  • 1
  • 12
  • 25
  • this answer is just a suggestion to liven up your question and make it go up the questions list again, I'm still willing and waiting to see if anyone has a better answer than mine – Omar Shawky Sep 13 '21 at 21:28
  • Sorry, i forgot to mention that I tried the START_STICKY too and didn't work – adam zverina Sep 14 '21 at 06:11