Your definition of how START_STICKY works is different from the documentation<http://developer.android.com/reference/android/app/Service.html#START_STICKY> :
if this service's process is killed while it is started (after returning from onStartCommand(Intent, int, int)<http://developer.android.com/reference/android/app/Service.html#onStartCommand(android.content.Intent, int, int)>), then leave it in the started state but don't retain this delivered intent. Later the system will try to re-create the service. Because it is in the started state, it will guarantee to call onStartCommand(Intent, int, int)<http://developer.android.com/reference/android/app/Service.html#onStartCommand(android.content.Intent, int, int)> after creating the new service instance; if there are not any pending start commands to be delivered to the service, it will be called with a null intent object, so you must take care to check for this. This describes exactly what I want to have happen. This is exactly what does happen on Android < 2.3. On Android 2.3 (and possibly 3.0), this no longer occurs and breaks my app. I know using startForeground works, and I use it. That's the kludgy workaround I spoke of, because I don't need to *always* be on, I just need to be reliably restarted. > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
