前台服务被Android杀死

Question

更新: 我没有找到真正的解决方案。但我想出了一种方法，可以在蓝牙连接丢失时自动重新连接到以前的蓝牙设备。虽然这不是理想的解决方案，但似乎效果还不错。如果有更多关于此问题的建议，我很乐意听取。

我遇到了与此问题类似的情况：Service being killed while holding wake lock and after calling startForeground，包括设备（Asus Transformer）、服务停止前的时间长度（30-45分钟）、使用唤醒锁、使用startForeground()，以及如果应用程序在屏幕关闭时保持打开，则不会出现此问题。

我的应用程序维护与另一个设备的蓝牙连接，并在两者之间发送数据，因此必须始终处于活动状态以侦听数据。用户可以随意启动和停止服务，实际上这是我实现启动或停止服务的唯一方式。一旦服务重新启动，与其他设备的蓝牙连接就会丢失。

根据链接问题中的答案，startForeground()“减少了服务被终止的可能性，但并不能完全防止它”。我理解这就是情况，但我看到许多其他应用程序的示例没有这个问题（例如Tasker）。

如果服务无法一直运行直到用户停止，我的应用程序的实用性将大大降低。有没有什么方法可以避免这种情况？

每当服务停止时，我在logcat中看到以下内容：

ActivityManager: No longer want com.howettl.textab (pid 32321): hidden #16
WindowManager: WIN DEATH: Window{40e2d968 com.howettl.textab/com.howettl.textab.TexTab paused=false
ActivityManager: Scheduling restart of crashed service com.howettl.textab/.TexTabService in 5000ms

编辑：我还应该注意到，这种情况似乎不会发生在我连接的另一台设备上：运行Cyanogen的HTC Legend。

编辑：以下是adb shell dumpsys activity services的输出：

* ServiceRecord{40f632e8 com.howettl.textab/.TexTabService}

intent={cmp=com.howettl.textab/.TexTabService}

packageName=com.howettl.textab

processName=com.howettl.textab

baseDir=/data/app/com.howettl.textab-1.apk

resDir=/data/app/com.howettl.textab-1.apk

dataDir=/data/data/com.howettl.textab

app=ProcessRecord{40bb0098 2995:com.howettl.textab/10104}

isForeground=true foregroundId=2 foregroundNoti=Notification(contentView=com.howettl.textab/0x1090087 vibrate=null,sound=null,defaults=0x0,flags=0x6a)

createTime=-25m42s123ms lastActivity=-25m42s27ms

 executingStart=-25m42s27ms restartTime=-25m42s124ms

startRequested=true stopIfKilled=false callStart=true lastStartId=1

Bindings:

* IntentBindRecord{40a02618}:

  intent={cmp=com.howettl.textab/.TexTabService}

  binder=android.os.BinderProxy@40a9ff70

  requested=true received=true hasBound=true doRebind=false

  * Client AppBindRecord{40a3b780 ProcessRecord{40bb0098 2995:com.howettl.textab/10104}}

    Per-process Connections:

      ConnectionRecord{40a76920 com.howettl.textab/.TexTabService:@40b998b8}

All Connections:

  ConnectionRecord{40a76920 com.howettl.textab/.TexTabService:@40b998b8}

adb shell dumpsys activity的输出结果：

* TaskRecord{40f5c050 #23 A com.howettl.textab}

numActivities=1 rootWasReset=false

affinity=com.howettl.textab

intent={act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=com.howettl.textab/.TexTab}

realActivity=com.howettl.textab/.TexTab

lastActiveTime=4877757 (inactive for 702s)

* Hist #1: ActivityRecord{40a776c8 com.howettl.textab/.TexTab}

    packageName=com.howettl.textab processName=com.howettl.textab

    launchedFromUid=2000 app=ProcessRecord{40bb0098 2995:com.howettl.textab/10104}

    Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=com.howettl.textab/.TexTab }

    frontOfTask=true task=TaskRecord{40f5c050 #23 A com.howettl.textab}

    taskAffinity=com.howettl.textab

    realActivity=com.howettl.textab/.TexTab

    base=/data/app/com.howettl.textab-1.apk/data/app/com.howettl.textab-1.apk data=/data/data/com.howettl.textab

    labelRes=0x7f060000 icon=0x7f020000 theme=0x0

    stateNotNeeded=false componentSpecified=true isHomeActivity=false

    configuration={ scale=1.0 imsi=0/0 loc=en_CA touch=3 keys=2/1/1 nav=1/2 orien=L layout=0x10000014 uiMode=0x11 seq=6}

    launchFailed=false haveState=true icicle=Bundle[mParcelledData.dataSize=1644]

    state=STOPPED stopped=true delayedResume=false finishing=false

    keysPaused=false inHistory=true visible=false sleeping=true idle=true

    fullscreen=true noDisplay=false immersive=false launchMode=2

    frozenBeforeDestroy=false thumbnailNeeded=false

    connections=[ConnectionRecord{40a76920 com.howettl.textab/.TexTabService:@40b998b8}]

...

Proc #15: adj=prcp /F 40e75070 959:android.process.acore/10006 (provider)

          com.android.providers.contacts/.ContactsProvider2<=Proc{40bb0098 2995:com.howettl.textab/10104}

Proc #16: adj=bak+2/F 40bb0098 2995:com.howettl.textab/10104 (foreground-service)

这些似乎显示该服务正在前台运行。

- howettl

---

请看一下这个答案-也许适合你使用 https://dev59.com/n2Ij5IYBdhLWcg3wGRiM#21157035 - Muzikant

Answer 1

好的，我已经经历了这个问题的磨难。以下是如何进行的方式。有些 bug。本帖介绍了如何分析实现中的错误并解决问题。

简要总结一下，以下是事情应该如何运作。运行服务将定期清理和终止，大约每 30 分钟一次。希望长时间保持活动状态的服务必须调用 Service.startForeground，这会在通知栏上放置一个通知，以便用户知道您的服务正在永久运行并可能吸取电池寿命。任何时候只有 3 个服务进程可以自我提名为前台服务。如果有超过三个前台服务，则 Android 将提名最旧的服务作为清理和终止的候选项。

不幸的是，Android 在优先处理前台服务方面存在 bug，这些 bug 由服务绑定标志的各种组合触发。即使您已正确将服务提名为前台服务，如果使用某些绑定标志与您进程中的服务之间曾经建立过连接，Android 仍然可能终止您的服务。详细信息如下。

请注意，只有极少数服务需要成为前台服务。通常，只有在具有可随时打开和关闭或被用户取消的某种类型的持续活动或长时间运行的互联网连接时，才需要成为前台服务。需要前台状态的服务示例：UPNP 服务器、下载非常大文件的长时间运行、通过 Wi-Fi 同步文件系统和播放音乐。

如果您只是偶尔轮询，或者等待系统广播接收器或系统事件，则最好使用计时器或响应广播接收器唤醒您的服务，然后让您的服务完成后死亡。这是服务的预期行为。如果您必须保持活动状态，则请继续阅读。

在勾选了众所周知的要求（例如调用 Service.startForeground）之后，下一个要查看的地方是您在 Context.bindService 调用中使用的标志。用于绑定的标志以各种意想不到的方式影响目标服务进程的优先级。特别是，使用某些绑定标志可能会导致 Android 错误地将您的前台服务降级为普通服务。用于分配进程优先级的代码已经被大幅修改。值得注意的是，在 API 14+ 中存在修订，当使用旧的绑定标志时可能会导致 bug；在 4.2.1 中存在明显的 bug。

在所有这些情况下，sysdump 实用程序都是您的朋友，它可以用于确定 Activity 管理器分配给您的服务进程的优先级，并发现其分配了错误的优先级的情况。让您的服务运行起来，然后从主机计算机上的命令提示符中发出以下命令：

adb shell dumpsys activity processes > tmp.txt

使用记事本（不是写字板/写作）查看内容。

首先验证您是否已成功将服务运行在前台状态下。dumpsys 文件的第一部分包含每个进程的 ActivityManager 属性描述。在 dumpsys 文件的第一部分中查找与您的应用程序对应的以下行：

APP UID 10068 ProcessRecord{41937d40 2205:tunein.service/u0a10068}

请检查以下部分中的foregroundServices=true。不必担心隐藏和空设置；它们描述了进程中活动的状态，并不太相关于其中有服务的进程。如果foregroundService不是true，则需要调用Service.startForeground将其设为true。

接下来，您需要查看文件末尾附近标题为“按oom_adj排序的进程LRU列表”的部分。此列表中的条目可让您确定Android是否实际将您的应用程序分类为前台服务。如果您的进程在此列表底部，则它是摧毁的主要候选项。如果您的进程接近列表顶部，则几乎无法被摧毁。

让我们看一下此表中的一行：

  Proc #31: adj=prcp /FS trm= 0 2205:tunein.service/u0a10068 (fg-service)

这是一个示例前台服务，已经完成了所有正确的操作。关键字段是“ adj =”字段，它指示在ActivityManagerService完成所有操作后分配给您的进程的优先级。您希望它是“adj = prcp”（可见前台服务）;或“adj = vis”（具有活动的可见进程）或“fore”（具有前台活动的进程）。如果它是“ adj = svc”（服务进程），或“ adj = svcb”（传统服务？）或“ adj = bak”（空闲后台进程），则您的进程很可能会被终止，即使没有压力要回收内存，也不会少于每30分钟一次。行末的标签大多是 Google 工程师的诊断调试信息。根据 adj 字段做出终止决策。简要来说，/FS 表示前台服务；/FA 表示具有活动的前台进程。/B 表示后台服务。结尾处的标签表示赋予该进程优先级的一般规则。通常它应该与 adj = 字段匹配；但是，由于与其他服务或活动的活动绑定上绑定标志的影响，adj = 值在某些情况下可以向上或向下调整。

如果您遇到了绑定标志的错误，dumpsys 行将如下所示：

  Proc #31: adj=bak /FS trm= 0 2205:tunein.service/u0a10068 (fg-service)

请注意，adj字段的值被错误地设置为“adj = bak”（空的后台进程），这大致相当于“请请终止我，以便我结束这个毫无意义的存在”，以进行进程清理。还要注意行末的（fg-service）标志，表示“使用前台服务规则来确定adj设置”。尽管使用了fg-service规则，但是该进程被分配了一个adj设置“bak”，并且它不会存活很长时间。简而言之，这是一个bug。

因此，目标是确保您的进程始终获得“adj = prcp”（或更好）。实现该目标的方法是调整绑定标志，直到避免优先级分配中的错误。

以下是我知道的错误。（1）如果任何服务或活动曾经使用Context.BIND_ABOVE_CLIENT绑定到服务，则存在将adj =设置降级为“bak”的风险，即使该绑定不再活动。如果您还有服务之间的绑定，则尤其如此。这是4.2.1源代码中的明显错误。（2）绝对不要在服务到服务绑定中使用BIND_ABOVE_CLIENT。也不要在活动到服务连接中使用它。用于实现BIND_ABOVE_CLIENT行为的标志似乎是基于进程而不是基于连接设置的，因此即使没有设置带有该标志的活动到服务绑定，它也会触发服务到服务绑定的错误。当进程中有多个服务时，建立优先级也似乎存在问题。在服务到服务绑定上使用Context.BIND_WAIVE_PRIORITY（API 14）似乎有所帮助。从Activity到服务进行绑定时，Context.BIND_IMPORTANT似乎是一个比较好的选择。这样做可以在Activity在前台时将您的进程优先级提高一档，在Activity暂停或完成时不会造成任何明显的影响。

但总体而言，策略是调整bindService标志，直到sysdump指示您的进程已接收到正确的优先级。

对于我的目的，对于Activity-to-service绑定，使用Context.BIND_AUTO_CREATE | Context.BIND_IMPORTANT，对于service-to-service绑定，使用Context.BIND_AUTO_CREATE | Context.BIND_WAIVE_PRIORITY似乎是正确的选择。您的结果可能会有所不同。

我的应用程序相当复杂：两个后台服务，每个服务都可以独立地持有前台服务状态，另外一个也可以采用前台服务状态；其中两个服务有条件地绑定到彼此；第三个服务始终绑定到第一个服务。此外，活动在单独的进程中运行（使动画更加流畅）。将活动和服务运行在同一个进程中似乎没有任何区别。

进程清理规则的实现（以及用于生成sysdump文件内容的源代码）可以在核心android文件中找到。

frameworks\base\services\java\com\android\server\am\ActivityManagerService.java.

祝你好运。

附注：这是Android 5.0的sysdump字符串的解释。我没有使用过它们，所以请自行理解。我相信你希望4成为“A”或“S”，5成为“IF”或“IB”，1尽可能低（可能低于3，因为默认配置中仅保留3个前台服务进程处于活动状态）。

Example:
   Proc # : prcp  F/S/IF trm: 0 31719: neirotech.cerebrum.attention:blePrcs/u0a77 (fg-service)

Format:
   Proc # {1}: {2}  {3}/{4}/{5} trm: {6} {7}: {8}/{9} ({10}

1: Order in list: lower is less likely to get trimmed.

2: Not sure.

3:
    B: Process.THREAD_GROUP_BG_NONINTERACTIVE
    F: Process.THREAD_GROUP_DEFAULT

4:
    A: Foreground Activity
    S: Foreground Service
    ' ': Other.

5:
    -1: procState = "N ";
        ActivityManager.PROCESS_STATE_PERSISTENT: procState = "P ";
    ActivityManager.PROCESS_STATE_PERSISTENT_UI:procState = "PU";
    ActivityManager.PROCESS_STATE_TOP: procState = "T ";
    ActivityManager.PROCESS_STATE_IMPORTANT_FOREGROUND: procState = "IF";
    ActivityManager.PROCESS_STATE_IMPORTANT_BACKGROUND: procState = "IB";
    ActivityManager.PROCESS_STATE_BACKUP:procState = "BU";
    ActivityManager.PROCESS_STATE_HEAVY_WEIGHT: procState = "HW";
    ActivityManager.PROCESS_STATE_SERVICE: procState = "S ";
    ActivityManager.PROCESS_STATE_RECEIVER: procState = "R ";
    ActivityManager.PROCESS_STATE_HOME: procState = "HO";
    ActivityManager.PROCESS_STATE_LAST_ACTIVITY: procState = "LA";
    ActivityManager.PROCESS_STATE_CACHED_ACTIVITY: procState = "CA";
    ActivityManager.PROCESS_STATE_CACHED_ACTIVITY_CLIENT: procState = "Ca";
    ActivityManager.PROCESS_STATE_CACHED_EMPTY: procState = "CE";

{6}: trimMemoryLevel

{8} Process ID.
{9} process name
{10} appUid 

- Robin Davies

---

@Robin Davies，我有一个小问题。如果我需要一个持续运行的服务，我真的需要调用bindService()吗？只调用服务中的startForeground()是否足够？我使用EventBus与服务器进行通信。 - ar-g

很棒的帖子！已点赞。我想补充一点相关内容，如果你想要一个持续运行的服务，就像Robin提到的那样，你需要以某种方式启动它。可以在活动中直接调用startService(Intent service)方法，而不是bindService()，然后在服务启动后调用startForeground()方法。我在服务类的onStartCommand()方法中调用了这个方法。据我所知，这应该使你的服务没有绑定，但保持其运行，直到出现资源问题。希望对某人有所帮助。 - Dave

@Dave 嘿，Dave，我正是使用了那种方法，同时也返回了START_STICKY，但是我的服务在设备空闲一小时左右后总是会死掉。你有什么想法吗？ - Ruchir Baronia

嗨@RobinDavies，你能告诉我你所说的那个声明的参考资料吗，“在任何给定时间，只有3个服务进程可以将自己提名为前台服务。”？我认为我们正在遇到这个问题，但需要验证这是否是操作系统的运行方式。 - William Grand

@mcfisty：我的服务确实在单独的进程中运行。 - Robin Davies

Answer 2

如果它说“不再需要……”，那么该进程中没有处于startForeground()状态的活动服务。请检查确保您对其的调用实际上是成功的——即您看到通知已发布，此时日志中没有任何关于任何内容的消息等。还可以使用“adb shell dumpsys activity services”查看服务的状态，并确保它实际上被标记为前台。如果它正确地位于前台，则在显示进程的OOM adj的部分中，您将看到您的进程当前处于前台级别，因为该服务。

- hackbod

---

谢谢您的帮助！我已经编辑了我的问题，并附上了您提到的命令的输出。它们似乎表明该服务正在前台运行。 - howettl

我能贴一段代码以帮助诊断吗？ - howettl

它绝对不应该在前台被杀死，我确定标准平台中的音乐等东西也不会被杀死。考虑提交一个带有重现问题代码的错误报告。需要注意的一点是，如果您在任何时候进入和退出前台，可能会导致它被杀死。 - hackbod

调用notify()更新正在进行的通知而不是再次调用startForeground()，是否可能将其从前台状态中移除？如果有FLAG_ALERT_ONLY_ONCE启用在通知上是否会有影响？ - howettl

绝对不要通过通知管理器更新它。您是通过服务发布此内容的，应该继续通过服务更新它。 - hackbod