前景服务被Android杀死

更新:我还没有找到问题的真正解决方案。我所做的是一种在连接丢失时自动重新连接到以前的蓝牙设备的方法。它并不理想,但似乎运作得相当好。我很想听到有关这个的更多建议。


我遇到的问题与此问题大致相同:服务在被唤醒时被杀死并且在调用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

编辑:我还应该注意,这似乎没有出现在我连接的其他设备上:HTC Legend运行Cyanogen


编辑:这是输出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}


一只名叫tom的猫
浏览 456回答 3
3回答

jeck猫

行。我已经度过了难关,重新回到了这个问题上。这是如何进行的。有bug。该帖子描述了如何分析实现中的错误并解决问题。总结一下,这是事情应该如何运作。运行服务将定期清理并每30分钟左右终止一次。希望保持活动时间超过此时间的服务必须调用Service.startForeground,它会在通知栏上发出通知,以便用户知道您的服务是永久运行的并且可能会耗尽电池寿命。在任何给定时间,只有3个服务流程可以指定自己作为前台服务。如果有三个以上的前台服务,Android将提名最旧的服务作为清理和终止的候选者。不幸的是,Android中存在关于优先化前台服务的错误,这些错误由服务绑定标志的各种组合触发。即使您已正确地将您的服务提名为前台服务,但如果您使用某些绑定标志组合与您的流程中的服务建立了任何连接,则Android可能会终止您的服务。详情如下。请注意,很少有服务需要是前台服务。通常,如果您有一个可以打开或关闭或被用户取消的某种持续活动或长时间运行的互联网连接,您只需要成为前台服务。需要前台状态的服务示例:UPNP服务器,非常大的文件的长期下载,通过Wi-Fi同步文件系统,以及播放音乐。如果您只是偶尔轮询,或等待系统广播接收器或系统事件,您最好在计时器上唤醒服务,或响应广播接收器,然后让服务一旦完成就死掉。这就是服务的设计行为。如果你只是必须活着,那么请继续阅读。检查了众所周知的需求框(例如,调用Service.startForeground)后,下一个要查看的是您在Context.bindService调用中使用的标志。用于绑定的标志以各种意外方式影响目标服务进程的优先级。最特别的是,使用某些绑定标志会导致Android错误地将前台服务降级为常规服务。用于分配流程优先级的代码已被大量推翻。值得注意的是,API 14+中的修订版在使用旧的绑定标志时可能会导致错误; 并且4.2.1中存在明确的错误。所有这些中的朋友都是sysdump实用程序,可用于确定活动管理器为您的服务进程分配的优先级,并发现已分配不正确优先级的情况。启动并运行服务,然后从主机上的命令提示符处发出以下命令:adb shell dumpsys活动进程> tmp.txt使用记事本(不是wordpad / write)来检查内容。首先验证您是否已成功设法在前台状态下运行服务。dumpsys文件的第一部分包含每个进程的ActivityManager属性的描述。在dumpsys文件的第一部分中查找与您的应用程序对应的以下行:APP UID 10068 ProcessRecord {41937d40 2205:tunein.service / u0a10068}在以下部分中验证foregroundServices = true。不要担心隐藏和空置设置; 它们描述了流程中的活动状态,并且似乎与其中包含服务的流程并不特别相关。如果foregroundService不为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”(具有活动的可见过程)或“前”(具有前景活动的过程)。如果它是“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)标志,表示“forground service rules”用于确定“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)似乎有所帮助。从Activity绑定到服务时,Context.BIND_IMPORTANT似乎是一个好主意。这样做会在活动处于前台时将您的流程优先级提高一级,而在暂停或完成活动时不会造成任何明显的伤害。但总体而言,策略是调整bindService标志,直到sysdump指示您的进程已收到正确的优先级。为了我的目的,使用Context.BIND_AUTO_CREATE | Activity.to-service绑定的Context.BIND_IMPORTANT和Context.BIND_AUTO_CREATE | 服务到服务绑定的Context.BIND_WAIVE_PRIORITY似乎做对了。您的里程可能不同。我的应用程序相当复杂:两个后台服务,每个后台服务可以独立保存前台服务状态,另外三个也可以采用前台服务状态; 其中两个服务有条件地相互绑定; 总是第三个与第一个结合。此外,Activites在一个单独的过程中运行(使动画更流畅)。在同一过程中运行活动和服务似乎没有任何区别。可以在核心android文件中找到清理进程规则的实现(以及用于生成sysdump文件内容的源代码)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_DEFAULT4:    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 

海绵宝宝撒

如果它说“不再需要......”那么该进程在其中没有活动的服务当前处于startForeground()状态。检查以确保您的呼叫实际上是成功的 - 您看到发布的通知,此时日志中没有消息抱怨任何事情等。还使用“adb shell dumpsys活动服务”来查看您的服务状态,并确保它实际上标记为前景。此外,如果它是正确的前景,那么在“adb shell dumpsys activity”的输出中,您将在显示由于该服务而您的进程当前处于前台级别的进程的OOM adj的部分中看到。

慕容森

Upvoted。我想在这篇评论中添加一篇,我认为这是相关的。如果你想要一个不断运行的服务,正如Robin所说,你需要以某种方式启动它。可以直接在activity中调用startService(Intent服务)而不是bindService(),然后在服务启动后调用startForeground()方法。我在服务类的onStartCommand()中调用它。据我所知,这应该使您的服务不受限制,但保持运行等待资源问题。希望这有助于某人。
打开App,查看更多内容
随时随地看视频慕课网APP