我正在使用一项服务，只要服务器中有新的更新可用，该服务就会更新我的应用程序。所以我的服务运行，它总是与服务器检查版本更新，如果我得到新版本更新，它将安装。
每当我关闭申请表taskmanager我的服务被杀死时，我的问题都会被杀死。我也在onstartcommand()中使用了START_STICKY，即使它不起作用。一旦stopped by taskmanager，是否有机会重新启动我的服务。
您可以使用 AlarmManager 定期唤醒您的应用程序（即活动或服务）。这样，您就不需要一直在后台运行服务。
只需将 AlarmManager 设置为每天/每周唤醒您的应用程序/服务，检查更新，然后关闭服务。查看本教程，了解如何使用 AlarmManager。
这种方法将比运行自己的服务更好，因为它不使用内存或电池电源。您的用户会为此感谢您！
如果您的应用程序设计为在 API 级别 21 或更高版本（即 Android 5.0 棒棒糖）上运行，您还可以利用 JobScheduler。它可能很有用，即它可以安排更新检查在设备插入时运行，以进一步节省电量。
从文档中：
请注意，onStartCommand（） 方法必须返回一个整数。整数是一个值，用于描述系统在系统终止服务时应如何继续服务（如上所述，IntentService 的默认实现会为您处理此问题，尽管您可以修改它）。onStartCommand（） 的返回值必须是以下常量之一：
START_NOT_STICKY
如果系统在 onStartCommand（） 返回后终止服务，请不要重新创建服务，除非有挂起的意图要传递。这是避免在不必要的情况下运行服务以及应用程序可以简单地重新启动任何未完成的作业时运行服务的最安全选项。
START_STICKY 如果系统在 onStartCommand（） 返回后终止服务，请重新创建服务并调用 onStartCommand（），但不要重新传递最后一个意图。相反，系统会以空意图调用 onStartCommand（），除非有挂起的意图来启动服务，在这种情况下，将传递这些意图。这适用于不执行命令，但无限期运行并等待作业的媒体播放器（或类似服务）。
START_REDELIVER_INTENT
如果系统在 onStartCommand（） 返回后终止服务，请重新创建服务并使用传递给服务的最后一个意图调用 onStartCommand（）。任何挂起的意向都会依次传递。这适用于正在主动执行应立即恢复的作业（如下载文件）的服务。
您是否尝试过用START_REDELIVER_INTENT归还onStartCommand()？
您可以在 TaskRemove 上使用此方法，通过 BroadcastReceiver 再次启动服务。