android - Android:以巨大的延迟调度崩溃服务的重启？

我有一个正在运行的服务，操作系统正在关闭它，问题是当它关闭它并安排重新启动时，它被安排在一个小时后重新启动。此服务维护两个接收器以进行蓝牙连接更改，因此我需要更快地重新启动，而不是在“重新启动”状态下等待一个多小时。
这是从日志中截取的一个片段：

I/ActivityManager( 1064): No longer want com.deadbeat.bta (pid 25455): hidden #17
W/ActivityManager( 1064): Scheduling restart of crashed service com.deadbeat.bta/com.deadbeat.btalib.BTService in 3600210ms`

在这3600秒过去之后，它将简单地终止它，并在2小时后重新安排，以此类推。发生这种情况时，似乎没有调用ondestroy（）、oncreate（）和onstartcommand（）。启动主活动将成功地重新启动服务，在重新开始之前，几个小时内一切正常。
当我做了一个更改，需要在服务启动时传入附加项时，就会发生这种情况。
这是我的onstartcommand和oncreate，如果有帮助的话…

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    Log.d("BTA", ">>> onStartCommand()");
    setIntent(intent);

    Bundle extras = getIntent().getExtras();
    if (extras != null) {
        setGlobals((Globals) extras.getSerializable("Globals"));
    }
    if (getGlobals() == null) {
        Log.e("BTA", "!!! Call an ambulance!!");
    }
    Log.i(getGlobals().getLogPrefix(), ">>> Service starting up");

    setWorker(new BTAWorker(this, getGlobals()));
    getWorker().doLog("Service Worker Set and Active");

    return START_REDELIVER_INTENT;
}

@Override
public void onCreate() {
    // Create
    super.onCreate();
    Log.d("BTA", ">>> onCreate()");
    // Register BroadcastReceiver with connect and disconnect actions
    IntentFilter intentToReceiveFilter = new IntentFilter();
    intentToReceiveFilter.addAction("android.bluetooth.device.action.ACL_CONNECTED");
    intentToReceiveFilter.addAction("android.bluetooth.device.action.ACL_DISCONNECTED");
    registerReceiver(this.mIntentReceiver, intentToReceiveFilter, null, this.mHandler);
    Log.d("BTA", ">>> Bluetooth State Receiver registered");
    Log.d("BTA", ">>> Intent = " + getIntent());
}

任何关于我做错了什么的建议都将不胜感激。我已经搜索过了，但是没有发现任何与重启延迟这么长时间有关的东西。父活动是否必须处于活动状态才能工作？（因此，当清理主活动时，如果不重新打开主活动，就无法重新启动服务？），还是发生了其他事情？

最佳答案

我完全处于同样的处境。重启时间在3m-9ms左右非常长。
我对这个问题做了很多研究，很多次我发现StartForeground可以解决所有问题。但我对这个解决方案不满意。
在我的情况下，我使用handlerThread处理后台任务，解决方案是将此线程优先级thread_priority_background更改为默认值。恼人的是，我在一个官方服务示例中找到了thread_priority_背景。
onstartcommand仍然没有被调用，但是在我将所有内容移动到oncreate之后（onstartcommand只是返回start_sticky），现在一切正常。