前台服务被Android杀死


84

更新我还没有找到解决该问题的真正方法。我想出的是一种在连接断开时自动重新连接到以前的蓝牙设备的方法。这不是理想的方法,但是看起来效果很好。我很乐意听到关于此的更多建议。

我遇到的问题与这个问题大致相同:按住唤醒锁并调用包括设备(Asus Transformer)的startForeground之后,服务被终止,服务停止之前的时间(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)

这些似乎表明服务正在前台运行。


看看这个答案-可能对您
有用

Answers:


217

对。我经历了地狱,回到了这个问题上。这是继续的方法。有错误。这篇文章描述了如何分析实现中的错误并解决问题。

总结一下,这就是应该如何工作的方式。定期对运行中的服务进行清理,并每30分钟左右终止一次。希望存活时间更长的服务必须调用Service.startForeground,该服务会在通知栏上放置一条通知,以便用户知道您的服务正在永久运行并有可能消耗电池寿命。在任何给定时间,只有3个服务进程可以提名自己为前台服务。如果有三个以上的前台服务,则Android将提名最早的服务作为清理和终止的候选人。

不幸的是,Android中存在有关优先考虑前台服务的错误,这些错误是由服务绑定标志的各种组合触发的。即使您已正确地将服务指定为前台服务,但如果通过绑定标志的某些组合进行过与服务中服务的任何连接,Android仍可能终止您的服务。细节在下面给出。

请注意,很少有服务需要是前台服务。通常,仅当您具有可以打开和关闭或被用户取消的某种持续活动或长期运行的Internet连接时,才需要成为前台服务。需要前台状态的服务示例:UPNP服务器,长期运行的大文件下载,通过wi-fi同步文件系统以及播放音乐。

如果您只是偶尔轮询,等待系统广播接收器或系统事件,则最好在计时器上唤醒服务或响应广播接收器,然后让服务在完成后终止。这就是服务的设计行为。如果您只是必须活着,请继续阅读。

选中了众所周知的要求(例如,调用Service.startForeground)的框后,接下来要看的地方是您在Context.bindService调用中使用的标志。用于绑定的标志以各种意外的方式影响目标服务进程的优先级。最特别的是,使用某些绑定标志可能会导致Android将您的前台服务错误地降级为常规服务。用于分配进程优先级的代码已被大量修改。值得注意的是,API 14+中的某些修订版在使用较旧的绑定标志时可能会导致错误;在4.2.1中有明确的错误。

在这一切中,您的朋友是sysdump实用程序,该实用程序可用于确定活动管理器为您的服务流程分配的优先级,并找出其分配了错误优先级的情况。启动并运行服务,然后从主机上的命令提示符处发出以下命令:

adb shell dumpsys活动进程> tmp.txt

使用记事本(而不是写字板/写字板)检查内容。

首先,验证您是否成功管理了在前台状态下运行的服务。dumpsys文件的第一部分包含每个进程的ActivityManager属性的描述。在dumpsys文件的第一部分中查找与您的应用程序对应的类似于以下内容的行:

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

在下一节中,验证frontgroundServices = true。不用担心隐藏和空白的设置;它们描述了流程中活动的状态,似乎与其中包含服务的流程没有特别的关系。如果前台服务不正确,则需要调用Service.startForeground使其正确。

接下来需要查看的是文件结尾附近的部分,标题为“ Process LRU list(按oom_adj排序):”。此列表中的条目可让您确定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”,它的寿命不会很长,简而言之,这是一个错误。

因此,目标是确保您的进程始终获得“ 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)似乎有所帮助。从活动绑定到服务时,Context.BIND_IMPORTANT似乎是一个好主意。这样做可以使您的流程优先级在“活动”处于前台时提高一个级别,而在“活动”暂停或完成时不会造成任何明显的危害。

但是总的来说,策略是调整您的bindService标志,直到sysdump指示您的进程已收到正确的优先级为止。

就我而言,使用Context.BIND_AUTO_CREATE | 用于活动到服务绑定的Context.BIND_IMPORTANT,以及Context.BIND_AUTO_CREATE | 服务到服务绑定的Context.BIND_WAIVE_PRIORITY似乎做对了。您的里程可能会有所不同。

我的应用程序非常复杂:两个后台服务,每个后台服务可以独立保存前台服务状态,另外三个还可以获取前台服务状态。其中两个服务有条件地相互绑定;第三,总是绑定到第一。此外,Activites在单独的过程中运行(使动画更流畅)。在同一过程中运行活动和服务似乎没有任何区别。

清除流程规则的实现(以及用于生成sysdump文件内容的源代码)可以在核心android文件中找到

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

好的机会。

PS:这是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 

4
@Robin Davies,我有一个小问题。bindService()如果需要持续运行Service,我真的需要打电话吗?仅仅startForeground()服务电话还不够吗?为了与服务器通信,我使用EventBus。
ar-g

您从Activity调用Context.bindService以便首先运行该服务。服务中的代码将调用Service.startService方法,以将已启动的服务移至“前台”状态。我假设EventBus库在某个时候代表您调用Context.bindService以便启动服务。如果还有另一种启动服务的方式,我对此并不熟悉。
罗宾·戴维斯

3
很棒的帖子!已投票。我想补充一点,我认为这是相关的。如果您想要一个持续运行的服务,如Robin所述,您需要以某种方式启动它。可以在活动内部直接调用startService(Intent service),而不是bindService(),然后一旦服务启动,您可以调用startForeground()方法。我在服务类的onStartCommand()中调用它。据我所知,这应该使您的服务不受限制,但要使其运行在未决资源问题上。希望这对某人有帮助。
戴夫

做得好!!我想对此进行更新。首先,adb的输出格式略有变化(2016年1月)。我已经在两个设备LG Volt 4.4.2和Nexus 5x 6.0.1上测试了此过程,但两个设备仍受此错误困扰。我只能使用Context.BIND_ABOVE_CLIENT来重现该问题:Proc#4:cch F / S / SF trm:0 12354:com.test / u0a78(fg-service)使用故障标志会导致大多数时间在较早版本上被立即杀死退出活动后的设备。所有其他标志似乎都可以在两个Android版本上正常工作。
user3259330'1

1
@Dave嘿,Dave,我完全使用该方法,并返回START_STICKY,但是设备闲置一小时左右后,我的服务总是会死掉。您对可能发生的事情有任何想法吗
Ruchir Baronia

7

如果说“不再想要...”,则该进程中没有活动的服务,该服务当前处于startForeground()状态。检查并确保对您的调用实际上是成功的-您正在看到通知的发布,此时日志中没有任何消息在抱怨任何东西,等等。也请使用“ adb shell dumpsys activity services”来查看服务状态,并确保将其实际标记为前台。同样,如果正确地是前台,那么在“ adb shell dumpsys activity”的输出中,您将在显示进程的OOM调整的部分中看到,由于该服务,您的进程当前处于前台级别。


感谢您的帮助!我已经用您提到的命令的输出编辑了我的问题。它们似乎表明该服务正在前台运行。
howettl 2011年

我是否可以发布一段有助于诊断的代码?
howettl 2011年

1
它绝对不应在前台被杀死,而且我可以肯定,标准平台中的诸如Music之类的东西并不是必需的。考虑使用代码提交错误以重现该问题。要看的一件事是,如果您在任何可能使其被杀死的位置上移入和移出前景。
hackbod 2011年

1
通过调用notify()而不是再次调用startForeground()来更新正在进行的通知是否有可能使其脱离前台状态?如果重要的话,我还会在通知中启用FLAG_ALERT_ONLY_ONCE。
howettl 2011年

2
绝对不要通过通知管理器更新它。您正在通过服务发布此信息,并且应该继续通过服务对其进行更新。
hackbod 2011年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.