使用
Android 9.0(Pie),用户可以限制您的应用程序通过设置进行后台工作.当我们尝试在Pie设备上启动前台服务时,如果应用程序受到后台限制,即使应用程序活动完全位于前台,我们的应用程序也会遇到以下异常.
RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
我们在启动的服务中调用startForeground(),但尝试启动服务时的系统日志显示:
system_process W/ActivityManager: Service.startForeground() not allowed due to bg restriction
当你跟踪the documented steps的前台服务时,看起来很奇怪,并且当你的应用程序也在前台时,系统拒绝启动前台服务的应用程序.我还没有找到与此相关的大量文档,但这是记录在案的行为吗?您的应用程序是否至少有一种方法可以知道它是否受到后台限制,因此不会尝试在前台启动服务?
我的服务代码基本上如下所示.我们的目标api是27.
class MyService : Service() {
override fun onCreate() {
super.onCreate()
// create notification
startForeground(NOTIFICATION_ID, notification)
}
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
if (intent == null || intent.action == null || intent.action == ACTION_STOP) {
quit()
}
doWork()
return START_NOT_STICKY
}
override fun onBind(intent: Intent?): IBinder? {
return null
}
override fun onTaskRemoved(rootIntent: Intent?) {
super.onTaskRemoved(rootIntent)
quit()
}
private fun quit() {
stopForeground(true)
stopSelf()
}
companion object {
fun start(context: Context) {
val intent = Intent(context, MyService::class.java)
intent.action = ACTION_START
ContextCompat.startForegroundService(context, intent)
}
fun stop(context: Context) {
val intent = Intent(context, MyService::class.java)
intent.action = ACTION_STOP
ContextCompat.startForegroundService(context, intent)
}
}
}
最佳答案 想知道崩溃实际上会发生在MyService.stop()中对ContextCompat.startForegroundService()的第二次调用,我用它来发送一个带有“停止”动作的Intent来停止服务而不是调用context.stopService( ).起初我虽然需要在服务中手动调用stopForeground(),但是调用context.stopService()似乎停止了前台服务并且仍然删除了通知并且不会导致崩溃,所以我决定重构我如何处理停止服务.
更新:我认为问题的另一部分还在尝试使用Intents来启动和停止服务,特别是因为在某些情况下我的服务已启动然后停止太快.一个非常有用的thread with Ian Lake提供了有关服务的这些建议:
I’d strongly suggest against using startService as a way to pass messages to your service. Using an EventBus or LocalBroadcastReceiver is a lot better way of passing messages without conflating that with lifecycle actions. I’d also avoid having external components call stopService() directly – let the service itself manage its own lifecycle, reacting to events you send its way.