7

In the Android documentation, the Service's "onStartCommand()" has an intent given as a param, that according to the docs:

"the Intent supplied to startService(Intent), as given. This may be null if the service is being restarted after its process has gone away, and it had previously returned anything except START_STICKY_COMPATIBILITY."

However, the return value START_REDELIVER_INTENT is supposed to return the original intent when restarting a service.

Can anyone explain why an intent can be null, even if the flag was set to START_REDELIVER_INTENT?

Yuxal
  • 445
  • 4
  • 14
  • +1: I'm observing the same behaviour: START_REDELIVER_INTENT gives null intents. However, most of the devices are of less well-known brands like Alps, Tecno and Wiko. I haven't seen any mainstream brands so far. – Roy Solberg Feb 24 '16 at 07:21
  • Actually, looking on some other issue I see that Google's own com.google.android.gms.measurement.AppMeasurementService crashes with NullPointerException in onStartCommand() on **Itel** devices. And it looks like they do a intent.getAction() without checking if intent is null. They use START_NOT_STICKY where the service isn't supposed to be restarted (which should avoid null intents). – Roy Solberg Feb 24 '16 at 07:41

1 Answers1

2

Are you possibly confusing START_FLAG_REDELIVERY with START_REDELIVER_INTENT? Your post says, "the return value START_FLAG_REDELIVERY". That constant is not one of the values returned from onStartCommand, it is one of the bit values passed into onStartCommand as the flags parameter. START_FLAG_REDELIVERY and START_STICKY both have value of 1. If you mistakenly have return START_FLAG_REDELIVERY at the end of onStartCommand(), the service will restart in sticky mode with a null intent if there are no start commends pending.

Bob Snyder
  • 37,759
  • 6
  • 111
  • 158