ACTION_BOOT_COMPLETED, IntentService, and Android 8.0

Another day, another unexpected side-effect of Android 8.0’s front in the War on Background Processing.

A Stack Overflow question pointed out an issue with ACTION_BOOT_COMPLETED . While this implicit broadcast is whitelisted, and so you can still receive it, your ability to actually do anything is limited. Your app is considered to be in the background, and therefore you cannot start an IntentService , as we have been doing for years.

So, here are some workarounds:

Workaround #1: startForegroundService()

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

import android.content.BroadcastReceiver; import android.content.Context; import android.content.Intent; import android.os.Build; public class OnBootReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { Intent i=new Intent(context, TestIntentService.class); if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.O) { context.startForegroundService(i); } else { context.startService(i); } } }

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 android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground() at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1775) at android.os.Handler.dispatchMessage(Handler.java:105) at android.os.Looper.loop(Looper.java:164) at android.app.ActivityThread.main(ActivityThread.java:6541) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)

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 shade.

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.

Need an extra hand with your Android app development project? CommonsWare can help — reach out for details!

— Jun 12, 2017