START_STICKY不会在Android奇巧（：和果冻豆编辑）工作？ [英] START_STICKY does not work on Android KitKat (Edit: And Jelly Bean)?

问题描述

我的一个应用程序有一个使用了 START_STICKY 返回code从 onStartCommand 来自动将backgrouod服务重新启动时，系统杀死它。 看来，这已不再是工作在Android奇巧。 对此有任何解决方案？ 我应该做不同的东西在奇巧，以保持业务正常运行？

One of my apps has a backgrouod service that uses the START_STICKY return code from onStartCommand to automatically restart when the system kills it. It seems that this is no longer working on Android KitKat. Is there any solution for this ? Should I be doing something different on Kitkat to keep the service running ?

注：有一个关于从最近的应用程序列表的行为刷卡应用程序在Android，Devlopers组类似的讨论。难道这两个问题有关？ https://groups.google.com/forum/# ！话题/ Android的开发者/ H-DSQ4-TIAC

Note: There is a similar discussion on the Android-Devlopers group about swiping the app from the recent apps list behaves. Could this two issues be related ? https://groups.google.com/forum/#!topic/android-developers/H-DSQ4-tiac

编辑：锯，有在​​Android的问题跟踪开放的错误：

Saw that there are open bugs on Android issue tracker:

HTTPS：//$c$c.google。 COM / P /安卓/问题/详细信息？ID = 63793 的https：//$c$c.google.com/p /安卓/问题/详细信息？ID = 63618

EDIT2：即使服务正在使用运行同样的情况， startForeground ，在一个单独的进程，并与标志安卓stopWithTask =假 在AndroidManifest.xml文件...

The same happens even if service is running using startForeground, in a separate process and with the flag android:stopWithTask="false" in the AndroidManifest.xml file...

EDIT3：在Android问题跟踪更多相关的问题：

More related bugs on Android issue tracker:

HTTPS：//$c$c.google。 COM / P /安卓/问题/详细信息？ID = 62091 的https：//$c$c.google.com/p /安卓/问题/详细信息？ID = 53313 的https：//$c$c.google.com/p /安卓/问题/详细信息？ID = 104308

有某种变通方法来获取previous行为？

Is there some sort of workaround to get the previous behavior ?

推荐答案

这是不是一个100％的工作解决方案，但它是迄今为止最好的，因为它几乎完全消除了该问题。到目前为止，我的综合沿着这个解决方案，覆盖 onTaskRemoved （请参见这个答案），并保持活动的通知（见这个答案）。 其他答案是非常AP preciated！

This is not a 100% working solution but it's the best so far as it almost completely eliminates the problem. So far I integrated this solution along with overriding onTaskRemoved (See this answer) and a keep-alive notification (See this answer). Additional answers are very appreciated !

经过进一步调查，似乎这个bug已经存在于果冻豆，看起来像有是一个解决方案（至少在我的情况下，似乎工作。将继续测试和更新的答案如果需要的话）。

After further investigation, it seems that the bug already exists in Jelly Bean and looks like there is a solution for that (At least in my case that seems to work. will keep on testing and update the answer if required).

据我观察这只是发生与接收 AlarmManager 设置广播服务。

From what I observed this only happens with services that receive broadcasts set by AlarmManager.

要重现错误请按照下列步骤操作：

To reproduce the bug follow these steps:

1. 在启动应用程序
2. 从应用程序中启动该服务作为前台服务（使用 startForeground 为）
3. 从轻扫最近的应用程序列表中的应用程序
4. 发送由服务处理的广播
5. 在该服务被杀死！

1. Start the app
2. start the service as a foreground service (use startForeground for that) from within the app
3. Swipe the app from "Recent Apps" list
4. Send a broadcast that is handled by the service
5. The service is killed !

使用亚行外壳dumpsys＆GT; C：\ dumpsys.txt 您可以监控不同步骤之间的服务的状态。 （在dumpsys输出查找进程LRU列表） 在步骤2和3，你会看到这样的事情：

Using adb shell dumpsys >C:\dumpsys.txt you can monitor the state of the service between the different steps. (look for Process LRU list in the dumpsys output) on steps 2 and 3 you will see something like this:

Proc # 2: prcp  F/S/IF trm: 0 11073:<your process name>/u0a102 (fg-service)

具体地讲，注意 F / S / IF 和（FG-服务），表明该服务运行作为前台服务（关于如何分析dumpsys在此链接的详细信息：<一href="http://stackoverflow.com/a/14293528/624109">http://stackoverflow.com/a/14293528/624109).

Specifically, notice the F/S/IF and the (fg-service) that indicate the service is running as a foreground service (more details on how to analyze the dumpsys at this link: http://stackoverflow.com/a/14293528/624109).

第4步后，你将不会看到进程LRU列表为您服务。 相反，你可以看一下该设备的logcat，你会看到以下内容：

After step 4 you will not see your service in the Process LRU list. Instead, you can look at the device logcat and you will see the following:

I/ActivityManager(449): Killing 11073:<your process name>/u0a102 (adj 0): remove task

什么似乎导致这种行为是接收广播采用的服务出了它的前景状态，然后杀害的事实。

What seems to be causing that behavior is the fact that the received broadcast takes the service out of its foreground state and then killed.

要避免这种情况，可以在创建时使用的简单解决方案，你的 PendingIntent 为 AlarmManager （来源：<一href="https://$c$c.google.com/p/android/issues/detail?id=53313#c7">https://$c$c.google.com/p/android/issues/detail?id=53313#c7)

To avoid that, you can use this simple solution when creating your PendingIntent for the AlarmManager (Source: https://code.google.com/p/android/issues/detail?id=53313#c7)

AlarmManager am = (AlarmManager)getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent("YOUR_ACTION_NAME");
intent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 1, intent, 0);

讲究以下步骤：

Pay attention to the following steps:

对意图
1. 呼叫addFlags并使用<一个href="http://developer.android.com/reference/android/content/Intent.html#FLAG_RECEIVER_FOREGROUND"><$c$c>FLAG_RECEIVER_FOREGROUND
2. 使用非零请求code在PendingIntent.getBroadcast

如果你留下任何这些措施出来是行不通的。

If you leave any of those steps out it will not work.

请注意，<一个href="http://developer.android.com/reference/android/content/Intent.html#FLAG_RECEIVER_FOREGROUND"><$c$c>FLAG_RECEIVER_FOREGROUND加入的API 16（果冻豆），所以它是有道理的，这是当错误第一次出现...

Note that the FLAG_RECEIVER_FOREGROUND was added on API 16 (Jelly Bean) so it makes sense that this is when the bug first appeared...

最有可能的奇巧只是更积极的，当谈到杀死进程，这就是为什么它被用奇巧强调，不过貌似这已经是相关的果冻豆。

Most likely that KitKat is just more aggressive when it comes to killing processes and this is why it was emphasized with KitKat, but looks like this was already relevant on Jelly Bean.

注2：请注意，在对服务配置的问题的细节 - 在一个单独的进程中运行，作为前台服务，与endWithTask设置为false在清单

Note 2: Notice the details in the question about the service configuration - running in a separate process, as a foreground service, with endWithTask set to false in the manifest.

注3：当应用程序接收到 android.appwidget.action.APPWIDGET_CONFIGURE 消息，并给出了一个新的小部件配置活动发生同样的事情（更换上面的步骤4以建立一个新的widget）。我发现，当小部件供应商（即处理接收 android.appwidget.action.APPWIDGET_UPDATE ）设置为一个不同的过程比活动的进程中运行，只有发生。改变这种所以无论是配置活动和小窗口提供者都在同一过程之后，这将不再发生。

Note 3: The same thing happens when the app receives the android.appwidget.action.APPWIDGET_CONFIGURE message and shows a configuration activity for a new widget (Replace step 4 above with creating a new widget). I found that only happens when the widget provider (the receiver that handles android.appwidget.action.APPWIDGET_UPDATE) is set to run on a different process than the activity process. After changing that so both the configuration activity and the widget provider are on the same process, this no longer happens.

这篇关于START_STICKY不会在Android奇巧（：和果冻豆编辑）工作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！