Runtime exception Android O with boot_completed

Here are some options that I outlined in a blog post:

Workaround #1: startForegroundService()

Your BroadcastReceiver that receives the ACTION_BOOT_COMPLETED broadcast
could call startForegroundService() instead of startService() when on Android

import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.os.Build;

public class OnBootReceiver extends BroadcastReceiver {

  public void onReceive(Context context, Intent intent) {
    Intent i=new Intent(context, TestIntentService.class);

    else {

Note that this works, to an extent, even if your service does not actually
ever call startForeground(). You are given a window of time to get around
to calling startForeground(), “comparable to the ANR interval to do this”.
If your work is longer than a millisecond but less than a few seconds,
you could skip the Notification and the startForeground() call. However,
you will get an error in LogCat:

E/AndroidRuntime: FATAL EXCEPTION: main
 Process: com.commonsware.myapplication, PID: 5991 Context.startForegroundService() did not then call Service.startForeground()
     at android.os.Handler.dispatchMessage(
     at android.os.Looper.loop(
     at java.lang.reflect.Method.invoke(Native Method)

Of course, if you do not mind having a Notification briefly, you are welcome
to use startForeground() as Android expects you to, in which case you can
do background work normally, albeit with an entry showing up in the user’s notification

Workaround #2: goAsync()

BroadcastReceiver has offered goAsync() since API Level 11. This allows your
receiver to do work off the main application thread, so you could get rid of the
IntentService entirely and move your code into the BroadcastReceiver.
You still only have the ANR
timeout period to work with, but you will not be tying up your main application
thread. This is better than the first workaround, insofar as it has the same
time limitation but avoids the nasty error. However, it does require some amount
of rework.

Workaround #3: JobScheduler

If your work will take more than a few seconds and you want to avoid the
Notification, you could modify your code to implement a JobService and
work with JobScheduler. This has the added advantage of only giving you
control when other criteria are met (e.g., there is a usable Internet
connection). However, not only does this require a rewrite, but JobScheduler
is only available on Android 5.0+, so if your minSdkVersion is less than 21,
you will need some other solution on the older devices.

UPDATE: Eugen Pechanec pointed out JobIntentService,
which is an interesting JobService/IntentService mashup.

Leave a Comment