我已经构建了一个服务来向各种活动广播计时器数据。通常它运行正常没有问题，但有一些ocassions当android重新启动它不能按预期工作。
它还有三个广播接收器：
1 - 屏幕关闭事件：为了停止广播计时器数据并在服务结束时在警报管理器中设置警报，因此我将能够播放最终通知以供用户参加。
2 - 事件屏幕：为了继续广播定时器数据。我也取消了任何暂停的警报。
3 - 警报接收器。这通常在屏幕关闭时触发，如1中所述。
我的服务以startForeground启动并返回START_REDELIVER_INTENT。由于开始意图具有初始计时器日期，我可以毫无问题地重新创建服务状态。广播报警接收器和onStartCommand共享相同的句柄意图例程以启动或继续服务。
这一切都很完美。对于短计时器（<30分钟）我没有发现任何问题。屏幕可以打开，关闭，从开启到关闭以及从关闭到开启的相同时间。活动也可以在前面或后面。我和所有可能的状态都在玩弄。在所有情况下，我的服务和活动都运行良好。
当一些计时器更长时（> 30分钟，通常我设置为35分钟），我的问题就出现了。有时可能是由于内存原因Android杀了我的服务。没关系，因为据我所知，Android会这样做，以改善用户体验。问题是，当我进入'设置/应用程序/服务'时，我可以看到我的服务处于'重启'状态。我怀疑这意味着Android还没有推出它，它已经被推翻了。它表明状态很长一段时间（我还没有耐心等待，如果它在另外半小时内发生变化......）
问题在于，当处于该状态时，这可能永远长久（我一直在研究并且服务从未启动），计时器（在我看来）达到超时，警报管理员启动我的意图，但由于我的服务还没有开始，广播没有注册，我不能做超时的工作人员（播放通知）。因此，用户不知道服务计时器已经结束，这是一个严重的问题。
这是非常好的。由于服务在几乎所有通过30分钟的运行中被杀死，而其他服务没有被杀死。
我的问题是：究竟发生了什么？如何才能正确处理这种情况，以便检测已正确触发的警报，或者更重要的是：如何强制重新启动服务？
添加一些帮助数据：
我的服务确实与其他服务相比内存非常少，并且也没有运行长时间操作，它只在屏幕打开时使用handler.postdelayed（“sendUpdatesToUI”，250），屏幕关闭时没有任何内容，只等警报管理员发出超时意图。
当达到时间并且用户打开活动时，它从服务接收到计时器数据广播意图，当看到时间到达时，它就会停止服务。
我理解并接受用户可以在他想要的时候终止服务，我接受了。这里的问题不是用户，而是Android重新启动服务。
当服务被杀死时，不会调用onDestroy。
使用2.3.4版本。
答案 0 :(得分：1)
经过大量调查后，我找到了解决问题的方法。这都是关于startForeGround函数的。我正在使用：
startForeground（0，不是）;
虽然这看起来很好并且在网络上的很多例子中都找到了，但正确的做法是使用0，而不是任何其他随机值：
startForeground（2765，不是），
这解决了这个问题。