我有一个小部件，当设备处于清醒状态时，它会相对频繁地进行更新，我在短短几天内就看到了数千次崩溃。

问题触发

我甚至在我的Pixel 3 XL上也注意到了这个问题，而我本以为这款设备负载并不大。所有代码路径都被startForeground()覆盖。但后来我意识到，在很多情况下，我的服务可以很快地完成工作。我认为触发我的应用程序的原因是，在系统真正抽出时间显示通知之前，服务已经结束。

解决方案/解决方案

我摆脱了所有的崩溃。我所做的就是删除对stopSelf()的调用。(我正在考虑延迟停止，直到我非常确定通知被显示，但我不希望用户看到通知，如果它不是必要的。)当服务空闲一分钟或系统正常销毁它而不抛出任何异常时。

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    stopForeground(true);
} else {
    stopSelf();
}

我一直在研究这个问题，这是我目前为止的发现。如果我们有类似这样的代码，就会发生崩溃:

MyForegroundService.java

public class MyForegroundService extends Service {
    @Override
    public void onCreate() {
        super.onCreate();
        startForeground(...);
    }
}

MainActivity.java

Intent serviceIntent = new Intent(this, MyForegroundService.class);
startForegroundService(serviceIntent);
...
stopService(serviceIntent);

异常在以下代码块中抛出:

ActiveServices.java

private final void bringDownServiceLocked(ServiceRecord r) {
    ...
    if (r.fgRequired) {
        Slog.w(TAG_SERVICE, "Bringing down service while still waiting for start foreground: "
                  + r);
        r.fgRequired = false;
        r.fgWaiting = false;
        mAm.mAppOpsService.finishOperation(AppOpsManager.getToken(mAm.mAppOpsService),
                    AppOpsManager.OP_START_FOREGROUND, r.appInfo.uid, r.packageName);
        mAm.mHandler.removeMessages(
                    ActivityManagerService.SERVICE_FOREGROUND_TIMEOUT_MSG, r);
        if (r.app != null) {
            Message msg = mAm.mHandler.obtainMessage(
                ActivityManagerService.SERVICE_FOREGROUND_CRASH_MSG);
            msg.obj = r.app;
            msg.getData().putCharSequence(
                ActivityManagerService.SERVICE_RECORD_KEY, r.toString());
            mAm.mHandler.sendMessage(msg);
         }
    }
    ...
}

这个方法在MyForegroundService的onCreate()之前执行，因为Android在主线程处理程序上安排了服务的创建，但在BinderThread上调用了bringdownservicelock，这是一个竞争条件。这意味着MyForegroundService没有机会调用start前台，这将导致崩溃。

为了解决这个问题，我们必须确保在MyForegroundService的onCreate()之前不调用bringdownservicellocked。

public class MyForegroundService extends Service {

    private static final String ACTION_STOP = "com.example.MyForegroundService.ACTION_STOP";

    private final BroadcastReceiver stopReceiver = new BroadcastReceiver() {
        @Override
        public void onReceive(Context context, Intent intent) {
            context.removeStickyBroadcast(intent);
            stopForeground(true);
            stopSelf();
        }
    };

    @Override
    public void onCreate() {
        super.onCreate();
        startForeground(...);
        registerReceiver(
            stopReceiver, new IntentFilter(ACTION_STOP));
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        unregisterReceiver(stopReceiver);
    }

    public static void stop(Context context) {
        context.sendStickyBroadcast(new Intent(ACTION_STOP));
    }
}

通过使用粘性广播，我们确保广播不会丢失，stopReceiver在MyForegroundService的onCreate()中注册后立即接收到停止意图。此时我们已经调用了startForeground(…)。我们还必须删除这个粘滞的广播，以防止下一次stopReceiver被通知。

请注意，sendStickyBroadcast方法已弃用，我仅将其用作解决此问题的临时方法。

好吧，我注意到的一些东西可能也会对其他人有所帮助。这是严格的测试，看看我是否能找出如何解决我所看到的事件。为了简单起见，假设我有一个从演示者调用这个的方法。

context.startForegroundService(new Intent(context, TaskQueueExecutorService.class));

try {
    Thread.sleep(10000);
} catch (InterruptedException e) {
    e.printStackTrace();
}       

这将导致同样的错误。在方法完成之前，服务不会启动，因此服务中没有onCreate()。

So even if you update the UI off the main thread, IF you have anything that might hold up that method after it, it won't start on time and give you the dreaded Foreground Error. In my case we were loading some things onto a queue and each called startForegroundService, but some logic was involved with each in the background. So if the logic took too long to finish that method since they were called back to back, crash time. The old startService just ignored it and went on it's way and since we called it each time, the next round would finish up.

这让我想知道，如果我从后台线程调用服务，它是否可以在启动时完全绑定并立即运行，因此我开始试验。即使这样不会立即启动，它也不会崩溃。

new Handler(Looper.getMainLooper()).post(new Runnable() {
        public void run() {
               context.startForegroundService(new Intent(context, 
           TaskQueueExecutorService.class));
               try {
                   Thread.sleep(10000);
               } catch (InterruptedException e) {
                  e.printStackTrace();
              }       
        }
});

我不会假装知道为什么它没有崩溃，尽管我怀疑这迫使它等待，直到主线程能够及时处理它。我知道将它绑定到主线程并不理想，但由于我的使用是在后台调用它，所以我并不真正关心它是否等待完成而不是崩溃。

现在在Android O，你可以设置后台限制如下

调用服务类的服务

Intent serviceIntent = new Intent(SettingActivity.this,DetectedService.class);
if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.O) {
    SettingActivity.this.startForegroundService(serviceIntent);
} else {
    startService(serviceIntent);
}

服务类应该是这样的

public class DetectedService extends Service { 
    @Override
    public IBinder onBind(Intent intent) {
        return null;
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        return START_STICKY;
    }

    @Override
    public void onCreate() {
        super.onCreate();
        int NOTIFICATION_ID = (int) (System.currentTimeMillis()%10000);
         if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            startForeground(NOTIFICATION_ID, new Notification.Builder(this).build());
        }


        // Do whatever you want to do here
    }
}

为什么这个问题会发生，因为Android框架不能保证你的服务在5秒内启动，但另一方面，框架确实有严格的限制前台通知必须在5秒内触发，而不检查框架是否试图启动服务。

这绝对是一个框架问题，但并不是所有面临这个问题的开发人员都尽力了:

一个通知必须同时在onCreate和onStartCommand中，因为如果你的服务已经被创建并且你的activity试图再次启动它，onCreate将不会被调用。 通知ID不能为0，否则即使原因不同，也会发生相同的崩溃。 在start前台之前不能调用stopSelf。

有了以上3个，这个问题可以减少一点，但仍然不是一个解决方案，真正的解决方案或让我们说的变通办法是把你的目标sdk版本降低到25。

请注意，Android P很可能仍然会有这个问题，因为谷歌甚至拒绝理解发生了什么，不相信这是他们的错，阅读#36和#56以获得更多信息

在我的例子中，我称之为上下文。在服务有机会在内部调用start前台之前，停止服务(外部服务)。