Obsolete
Status Update
No update yet.
Comments
mm...@commonsware.com
"App is permanently terminated along with any of its services."
No, it is not. The task and its process are terminated. This is not "permanent". AlarmManager alarms, for example, still work.
"App UI is terminated, service remains functional"
Note that this behavior has long been device-specific, as different device manufacturers have altered the behavior of the recent-tasks lists to do different things when the user takes action there.
"the recent task list is turned into a task killer force-stopping apps"
No, it does not. "Force stop" has a *very specific meaning* in Android development. It not only terminates the process, but moves the app into a state where none of its broadcast receivers will work again until the user manually launches the app from an icon. Swiping a task off the recent-tasks lists, in a stock Android 4.4 environment, does not have this effect. On some third-party devices, even prior to Android 4.4, swiping a task from the recent-tasks list *does* "force stop" the app, which is an unfortunate choice on the part of those device manufacturers.
No, it is not. The task and its process are terminated. This is not "permanent". AlarmManager alarms, for example, still work.
"App UI is terminated, service remains functional"
Note that this behavior has long been device-specific, as different device manufacturers have altered the behavior of the recent-tasks lists to do different things when the user takes action there.
"the recent task list is turned into a task killer force-stopping apps"
No, it does not. "Force stop" has a *very specific meaning* in Android development. It not only terminates the process, but moves the app into a state where none of its broadcast receivers will work again until the user manually launches the app from an icon. Swiping a task off the recent-tasks lists, in a stock Android 4.4 environment, does not have this effect. On some third-party devices, even prior to Android 4.4, swiping a task from the recent-tasks list *does* "force stop" the app, which is an unfortunate choice on the part of those device manufacturers.
cc...@gmail.com
@#1, I'm running stock 4.4.2 on a Nexus 5 and got the exact same report from 2 other users running 4.4.2 and 4.4.1.
"App is permanently terminated along with any of its services."
It's definitely confirmed, even though the Applictions/Running settings shows app as still running, it's actually not.
I've tried setting an alarm and I also verified it's not being triggered any longer.
"App UI is terminated, service remains functional"
I've tested my apps and services on a good dozen devices (HTC, Samsung, Sony, Nexus, Asus" and they all did the same, service was always restarted after app is killed.
What I'm referring to anyway is the stock behavior which will be duplicated to all devices running 4.4.X, maybe changed, but that's the foundation that's broken.
"the recent task list is turned into a task killer force-stopping apps"
Yes I know how a force-stop works, thanks, doesn't change the facts that removing an app from recent task list puts it in the same state as doing a force-stop, will never run again until manually started.
AGAIN, verified by those 2 users, service stopped for entire days, and I verified that too.
So, again and again, it's not an unfortunate choice from manufacturers it's a bug in the Android source code which will be used as the foundation of all other device's running Android 4.4.
For the story, doing a force-stop or swiping out GMail, G+ and the likes do not affect those apps, maybe because they are system apps, but nonetheless the whole stuff is really messed up and inconsistent.
"App is permanently terminated along with any of its services."
It's definitely confirmed, even though the Applictions/Running settings shows app as still running, it's actually not.
I've tried setting an alarm and I also verified it's not being triggered any longer.
"App UI is terminated, service remains functional"
I've tested my apps and services on a good dozen devices (HTC, Samsung, Sony, Nexus, Asus" and they all did the same, service was always restarted after app is killed.
What I'm referring to anyway is the stock behavior which will be duplicated to all devices running 4.4.X, maybe changed, but that's the foundation that's broken.
"the recent task list is turned into a task killer force-stopping apps"
Yes I know how a force-stop works, thanks, doesn't change the facts that removing an app from recent task list puts it in the same state as doing a force-stop, will never run again until manually started.
AGAIN, verified by those 2 users, service stopped for entire days, and I verified that too.
So, again and again, it's not an unfortunate choice from manufacturers it's a bug in the Android source code which will be used as the foundation of all other device's running Android 4.4.
For the story, doing a force-stop or swiping out GMail, G+ and the likes do not affect those apps, maybe because they are system apps, but nonetheless the whole stuff is really messed up and inconsistent.
mm...@commonsware.com
"I've tried setting an alarm and I also verified it's not being triggered any longer" -- and I've tried setting an alarm and I also verified that it is still being triggered, running stock 4.4.2 on a Nexus 4.
Since you are the one claiming this change in behavior, it is your job to provide a reproducible test case. Please feel free to do so.
Since you are the one claiming this change in behavior, it is your job to provide a reproducible test case. Please feel free to do so.
cc...@gmail.com
Sorry, stop wasting my time with useless and unrelated arguments:
1- you implicitly confirmed all background services will be stopped. That's the bug reported here.
2- the bug is not about an alarm, but a background STICKY service.
3- Is it your job to fix Android bugs? Feel free to do so or stop speaking as such.
1- you implicitly confirmed all background services will be stopped. That's the bug reported here.
2- the bug is not about an alarm, but a background STICKY service.
3- Is it your job to fix Android bugs? Feel free to do so or stop speaking as such.
mm...@commonsware.com
"stop wasting my time with useless and unrelated arguments"
I am correcting the flaws in your issue report. You are the one claiming, in the issue, that swiping the recent-tasks list force-stops the application. You did that twice, three times if "permanently deleted" is interpreted as meaning force-stopped.
"Is it your job to fix Android bugs?"
Part of what I do is monitor this issue list, looking for major uncovered problems, and I try to reproduce those where practical. Your repeated claims that swiping off the recent-tasks list force-stops the app would qualify as a major uncovered problem, and so I investigated. It took me less than five minutes to come up with counter-evidence on that portion of your issue, and much of that was waiting for Eclipse to start up.
I have no argument about the rest of your issue, outside of the force-stop aspects, in large part because I have not specifically tested the other aspects of your issue to see if I can reproduce them.
I am correcting the flaws in your issue report. You are the one claiming, in the issue, that swiping the recent-tasks list force-stops the application. You did that twice, three times if "permanently deleted" is interpreted as meaning force-stopped.
"Is it your job to fix Android bugs?"
Part of what I do is monitor this issue list, looking for major uncovered problems, and I try to reproduce those where practical. Your repeated claims that swiping off the recent-tasks list force-stops the app would qualify as a major uncovered problem, and so I investigated. It took me less than five minutes to come up with counter-evidence on that portion of your issue, and much of that was waiting for Eclipse to start up.
I have no argument about the rest of your issue, outside of the force-stop aspects, in large part because I have not specifically tested the other aspects of your issue to see if I can reproduce them.
cc...@gmail.com
@3, I confirm using an alarm will keep the whole app alive, process is not killed and services are not restarted. This is not documented as such either, and this has nothing to do with the bug reported anyway.
That said, I found the old behavior much better as it was really slimming down memory consumption of such apps.
That said, I found the old behavior much better as it was really slimming down memory consumption of such apps.
cc...@gmail.com
#4, didn't claim it was force-stopping, but merely acting as such.
Sorry but providing a complete project is a little time consuming, when it's actually being reproduced by many running 4.4.
Sorry I was being harsh too, I should have specified what's out of scope.
My service is running to listen to battery updates, and update its widgets and/or log the data to a DB. So I don't want to use an alarm to wake-up the device, but let Android OS wake-up the device to notify of new battery data.
When swipping away the UI, the service is terminated and the app/service will never run again until run manually.
Same goes for the widget (it seems as far as I tested it), it's no longer udpated!
If you still want to reproduce this you can download Android Tuner Free, open it, go in app settings (bottom of main screen), then battery, then monitoring, enable permanent monitoring. Go back to launcher, swipe app away. Process is gone forever even though Android Applications, Running shows app as running!
Again sorry for being rude, but the issue is definitely there and at first I didn't want to believe the users reporting it either! Because they never mentioned swiping the app away from recent tasks! Took me a day to figure that one out!
Sorry but providing a complete project is a little time consuming, when it's actually being reproduced by many running 4.4.
Sorry I was being harsh too, I should have specified what's out of scope.
My service is running to listen to battery updates, and update its widgets and/or log the data to a DB. So I don't want to use an alarm to wake-up the device, but let Android OS wake-up the device to notify of new battery data.
When swipping away the UI, the service is terminated and the app/service will never run again until run manually.
Same goes for the widget (it seems as far as I tested it), it's no longer udpated!
If you still want to reproduce this you can download Android Tuner Free, open it, go in app settings (bottom of main screen), then battery, then monitoring, enable permanent monitoring. Go back to launcher, swipe app away. Process is gone forever even though Android Applications, Running shows app as running!
Again sorry for being rude, but the issue is definitely there and at first I didn't want to believe the users reporting it either! Because they never mentioned swiping the app away from recent tasks! Took me a day to figure that one out!
eb...@gmail.com
Hi
I can confirm the reported issue completely.
The sticky service that updates my app_widget does not restart after being killed by swiping out the application from recent task list and still more it is not restarted also when the application is closed due to internal memory management without any action from user.
The issue is certainly new and tested on two nexus 5 and one nexus 4 devices with Android 4.4.2.
I can confirm the reported issue completely.
The sticky service that updates my app_widget does not restart after being killed by swiping out the application from recent task list and still more it is not restarted also when the application is closed due to internal memory management without any action from user.
The issue is certainly new and tested on two nexus 5 and one nexus 4 devices with Android 4.4.2.
in...@gmail.com
Hey,
I can confirm this issue too.
While the service is killed, it is still displayed as running in system settings.
A query for running services will also still return the service.
Tested on Nexus 5 4.2.2
I can confirm this issue too.
While the service is killed, it is still displayed as running in system settings.
A query for running services will also still return the service.
Tested on Nexus 5 4.2.2
ya...@gmail.com
[Comment deleted]
gl...@gmail.com
I can confirm this issue as well with my app; the problem only began with Android 4.4.
My app starts a service with START_STICKY flag. Users typically set the service to run at boot. There is an activity which interacts with the service, as well as notification icon(s) that update rather frequently from the service. The user can quit the program (which removes all notifications and stops the service) via a menu item in the activity.
Prior to Android 4.4, if users "cleared" my app from the recent apps list, there was no negative impact. The service kept running (or was stopped, and restarted a short time later), and the notification icons remained and continued to update appropriately.
In Android 4.4, 4.4.1, and 4.4.2, if a user clears the app from the recent apps list, the service is killed. I believe this is a bug because the notification icon(s) remain, however they stop updating (because the service is killed). If a user clicks on one of my notifications in the pulldown, the activity and service are restarted, and the icons resume updating.
My app starts a service with START_STICKY flag. Users typically set the service to run at boot. There is an activity which interacts with the service, as well as notification icon(s) that update rather frequently from the service. The user can quit the program (which removes all notifications and stops the service) via a menu item in the activity.
Prior to Android 4.4, if users "cleared" my app from the recent apps list, there was no negative impact. The service kept running (or was stopped, and restarted a short time later), and the notification icons remained and continued to update appropriately.
In Android 4.4, 4.4.1, and 4.4.2, if a user clears the app from the recent apps list, the service is killed. I believe this is a bug because the notification icon(s) remain, however they stop updating (because the service is killed). If a user clicks on one of my notifications in the pulldown, the activity and service are restarted, and the icons resume updating.
yo...@gmail.com
I started having this issue after updating my test device (stock, 2012 Nexus 7) to KitKat 4.4.2 as well. My music player depends on a STICKY background service. I use expanded notification controls with the service to allow users to control music playback outside the app.
Everything works perfectly when I leave the app in the "Recent Apps" list. However, the moment I swipe away the app from the list and tap on one of the notification controls, it immediately shuts down the entire process. This is the message I see in my LogCat output:
-----------------------------------------------------------------------------
I/MediaFocusControl(494): AudioFocus abandonAudioFocus() from android.media.AudioManager@42972688com.jams.music.player.Services.JamsMusicPlayerService$1@42880530
I/ActivityManager(494): Killing 14000:com.jams.music.player/u0a84 (adj 0): remove task
-----------------------------------------------------------------------------
As you can see, the app is explicitly killed (remove task). I'm not sure if this kills the entire process or if it only kills the service. Either way, the service stops running, music playback stops, and it completely ruins the point of my music player. I'm gonna see if changing the service's return type to something other than "START_STICKY" solves the issue. Will report back soon.
Also, here's a few other related/exact same bugs:
https://code.google.com/p/android/issues/detail?id=53313
https://groups.google.com/forum/#!topic/android-developers/LtmA9xbrD5A
Everything works perfectly when I leave the app in the "Recent Apps" list. However, the moment I swipe away the app from the list and tap on one of the notification controls, it immediately shuts down the entire process. This is the message I see in my LogCat output:
-----------------------------------------------------------------------------
I/MediaFocusControl(494): AudioFocus abandonAudioFocus() from android.media.AudioManager@42972688com.jams.music.player.Services.JamsMusicPlayerService$1@42880530
I/ActivityManager(494): Killing 14000:com.jams.music.player/u0a84 (adj 0): remove task
-----------------------------------------------------------------------------
As you can see, the app is explicitly killed (remove task). I'm not sure if this kills the entire process or if it only kills the service. Either way, the service stops running, music playback stops, and it completely ruins the point of my music player. I'm gonna see if changing the service's return type to something other than "START_STICKY" solves the issue. Will report back soon.
Also, here's a few other related/exact same bugs:
yo...@gmail.com
Not an official fix, but this seems to have straightened things out for me:
https://code.google.com/p/android/issues/detail?id=53313#c1
Like the poster mentioned, side effects unknown. I'll post back if I run into any issues with this approach. Google really needs to clean this mess up though. Before we know it, other manufacturers will start building their system images with this flaw and it'll spread to other devices.
Like the poster mentioned, side effects unknown. I'll post back if I run into any issues with this approach. Google really needs to clean this mess up though. Before we know it, other manufacturers will start building their system images with this flaw and it'll spread to other devices.
el...@gmail.com
Dear commonsware contributor, can you try the free GPS Monitor app?
https://play.google.com/store/apps/details?id=eu.illyrium.tools.gpsmonitor
It shows a notification telling you how many satellites are in view (and if you have a lock) whenever the GPS is being used.
It's a superb and now actually essential little app since KitKat sadly took away the blinking GPS status bar icon (star the relevant report here):
http://code.google.com/p/android/issues/detail?id=62634
Anyway, this app's service stops working if removed from the recent tasks list, try and see. You will no longer see the GPS Monitor icon appear in the status bar when you start/stop your maps.
It shows a notification telling you how many satellites are in view (and if you have a lock) whenever the GPS is being used.
It's a superb and now actually essential little app since KitKat sadly took away the blinking GPS status bar icon (star the relevant report here):
Anyway, this app's service stops working if removed from the recent tasks list, try and see. You will no longer see the GPS Monitor icon appear in the status bar when you start/stop your maps.
gl...@gmail.com
[Comment deleted]
gl...@gmail.com
The workaround from
dd...@gmail.com
@commonsware:
the scenario is described here:http://stackoverflow.com/questions/21073136/kitkat-service-is-null-after-exiting-main-activity
and it has been tested on Galaxy Nexus 4.4.2 and Nexus 7 4.4.2 (the same code works perfectly on Android 4.3).
the scenario is described here:
and it has been tested on Galaxy Nexus 4.4.2 and Nexus 7 4.4.2 (the same code works perfectly on Android 4.3).
mu...@gmail.com
Yes, I have the same issue with my app on google play. I had to set " excludeFromRecents="true" ", this way I could avoid the bug. It happens to me on Android 4.1.2, Motorola RAZRi, but not only on this device, my users reported it too.
If the service is running on its own process, why it stops after remove the app from recents ?
My service only crashes after the count up of my AlarmManager, it does not crashe until my alarm trigger. However, my app crashes, after a random time (can be seconds or even hours), it comes back and do not crash anymore. Looks like it restarted "in another context" or something.
If the service is running on its own process, why it stops after remove the app from recents ?
My service only crashes after the count up of my AlarmManager, it does not crashe until my alarm trigger. However, my app crashes, after a random time (can be seconds or even hours), it comes back and do not crash anymore. Looks like it restarted "in another context" or something.
an...@gmail.com
#19, same here, tried running the service in its own process, it gets killed anyway, but after 5 to 50 seconds! Using an alarm to restart the service is thus very unreliable. The service was started as a foreground (with notification) and it doesn't make any difference!
It seems the only alternatives is it use AlarmManager as a keep-alive mechanism, deteriorating this situation even more. While trying to "save memory/battery" with this change and get rid of badly behaving apps, they're only make it worse. How funny!
It seems the only alternatives is it use AlarmManager as a keep-alive mechanism, deteriorating this situation even more. While trying to "save memory/battery" with this change and get rid of badly behaving apps, they're only make it worse. How funny!
km...@gmail.com
My two cents for the above discussion of inconsistent observations between Mr. Murphy and cocouno.
Just ran some tests on a Nexus 5 with stock 4.4.2:
Prerequisites:
- A service with START_FOREGROUND
- An activity
- Some broadcast receivers
- A scheduled alarm manager event (wired to one of those receivers)
- My app has only one process for all components.
Test:
- Run the activity, exit it with Back, swipe away from the recents
Results:
- The background service does not get killed immediately, the process doesn't get killed either
**** However, and this is the really important part ***
The app's process gets killed on the next broadcast from the alarm manager. The broadcast never reaches the app's code, that is, the process is killed *before* broadcast delivery, not after.
As noted before, the service's status bar icon continues to show. This alone, to me, is 200% evidence that this is a bug.
- The next broadcast works properly, creating a new process for the app, and delivering the broadcast.
The interval between the "bad" and the "good" broadcast is of course app-dependent (if there is a next broadcast at all), and in general, can cause an arbitrarily large interval where the app appears to be running (status bar icon) but in fact does not.
- Logcat output:
>>> Swiped the task from recents:
03-04 15:12:13.943 I/KeepAliveService(31936): onTaskRemoved: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=org.kman.AquaMail/.ui.AccountListActivity }
>>> This is when my alarm's broadcast fired:
03-04 15:15:01.033 I/ActivityManager( 768): Killing 31936:org.kman.AquaMail/u0a80 (adj 0): remove task
03-04 15:16:01.033 W/BroadcastQueue( 768): Timeout of broadcast BroadcastRecord{43881810 u0 org.kman.AquaMail.ALARM_TICK} - receiver=null, started 60002ms ago
03-04 15:16:01.033 W/BroadcastQueue( 768): Receiver during timeout: ResolveInfo{43460008 org.kman.AquaMail/.core.AlarmReceiver m=0x0}
An almost exact issue was present in 4.1.1 (almost a year and a half ago). Here is a relevant discussion on @android-developers:
https://groups.google.com/d/msg/android-developers/LtmA9xbrD5A/a29R5xjKYucJ
More thoughts:
- The system code, since 4.1 or so, appears to try to be more clever than before about picking processes to kill, based on what they do, including broadcast receivers being fired. It appears that this does not work well, making wrong decisions, perhaps because the code considers only one, most recent, event (i.e. the fact that the process also has a foreground service is somehow forgotten when the broadcast is taken into consideration).
- The workaround posted on SO and elsewhere, sends a delayed broadcast with Intent.FLAG_RECEIVER_FOREGROUND inside onTaskRemoved. This, apparently, resets those silly "smarts" in system code.
It should work to add this flag to regular broadcasts used by an app, on the condition that it's added to *all of them*.
And some more:
Google's push for lower memory consumption since 4.1 is leaving behind serious bugs, which not only do not get fixed, but keep getting worse.
GCM should continue to work, and it works fine for Google's own apps, but not all third party apps can use it (e.g. mine is an email app, and has to connect to actual mail servers, not Google's GCM).
And not all apps are, or should be, structured like Google's own.
At the same time, some of Google's own apps stay in memory for long periods of time, making the whole effort look hypocritical. I'm sure that's not the intent, but really, shouldn't these behave better?
Some choice packages from $adb shell ps:
com.google.android.youtube (two processes, never ran YouTube on this device)
com.android.musicfx (never listened to music on this device)
com.google.android.partnersetup (setup? the device was fully set up a month or two ago)
com.google.android.apps.magazines (magazines? I've never viewed any magazines in Google Play)
com.google.android.apps.plus (I don't use G+ on this device)
com.redbend.vdmc (an OTA update checker? why does it keep running?)
Just ran some tests on a Nexus 5 with stock 4.4.2:
Prerequisites:
- A service with START_FOREGROUND
- An activity
- Some broadcast receivers
- A scheduled alarm manager event (wired to one of those receivers)
- My app has only one process for all components.
Test:
- Run the activity, exit it with Back, swipe away from the recents
Results:
- The background service does not get killed immediately, the process doesn't get killed either
**** However, and this is the really important part ***
The app's process gets killed on the next broadcast from the alarm manager. The broadcast never reaches the app's code, that is, the process is killed *before* broadcast delivery, not after.
As noted before, the service's status bar icon continues to show. This alone, to me, is 200% evidence that this is a bug.
- The next broadcast works properly, creating a new process for the app, and delivering the broadcast.
The interval between the "bad" and the "good" broadcast is of course app-dependent (if there is a next broadcast at all), and in general, can cause an arbitrarily large interval where the app appears to be running (status bar icon) but in fact does not.
- Logcat output:
>>> Swiped the task from recents:
03-04 15:12:13.943 I/KeepAliveService(31936): onTaskRemoved: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=org.kman.AquaMail/.ui.AccountListActivity }
>>> This is when my alarm's broadcast fired:
03-04 15:15:01.033 I/ActivityManager( 768): Killing 31936:org.kman.AquaMail/u0a80 (adj 0): remove task
03-04 15:16:01.033 W/BroadcastQueue( 768): Timeout of broadcast BroadcastRecord{43881810 u0 org.kman.AquaMail.ALARM_TICK} - receiver=null, started 60002ms ago
03-04 15:16:01.033 W/BroadcastQueue( 768): Receiver during timeout: ResolveInfo{43460008 org.kman.AquaMail/.core.AlarmReceiver m=0x0}
An almost exact issue was present in 4.1.1 (almost a year and a half ago). Here is a relevant discussion on @android-developers:
More thoughts:
- The system code, since 4.1 or so, appears to try to be more clever than before about picking processes to kill, based on what they do, including broadcast receivers being fired. It appears that this does not work well, making wrong decisions, perhaps because the code considers only one, most recent, event (i.e. the fact that the process also has a foreground service is somehow forgotten when the broadcast is taken into consideration).
- The workaround posted on SO and elsewhere, sends a delayed broadcast with Intent.FLAG_RECEIVER_FOREGROUND inside onTaskRemoved. This, apparently, resets those silly "smarts" in system code.
It should work to add this flag to regular broadcasts used by an app, on the condition that it's added to *all of them*.
And some more:
Google's push for lower memory consumption since 4.1 is leaving behind serious bugs, which not only do not get fixed, but keep getting worse.
GCM should continue to work, and it works fine for Google's own apps, but not all third party apps can use it (e.g. mine is an email app, and has to connect to actual mail servers, not Google's GCM).
And not all apps are, or should be, structured like Google's own.
At the same time, some of Google's own apps stay in memory for long periods of time, making the whole effort look hypocritical. I'm sure that's not the intent, but really, shouldn't these behave better?
Some choice packages from $adb shell ps:
com.android.musicfx (never listened to music on this device)
com.google.android.partnersetup (setup? the device was fully set up a month or two ago)
com.google.android.apps.magazines (magazines? I've never viewed any magazines in Google Play)
com.google.android.apps.plus (I don't use G+ on this device)
com.redbend.vdmc (an OTA update checker? why does it keep running?)
an...@gmail.com
The issue is much more complex than you think and there's no inconsistencies.
Running a service as foreground prevents the whole process/service from being killed, but only if service runs in the same process.
However the process is marked as "remove task" and the next non foreground broadcast that is received by the process will get the process killed. Make your broadcast foreground and the process won't be killed! However for those using intentfilters with SCREEN_ON/OFF are out of luck as those filters creates background broadcast and get the app killed, after the broadcast is handled!
The only inconsistencies where present until users admitted there are obvious bugs, noticeably the icon remaining in the status bar, the OS listing the service as still running while the process hosting it is nowhere to be found, etc...
Can't agree more about Google's own apps using sync and escaping this entirely, probably on purpose. However they obviously behave much more badly than any other apps as you point out, they run even if they were never used, ever.
Running a service as foreground prevents the whole process/service from being killed, but only if service runs in the same process.
However the process is marked as "remove task" and the next non foreground broadcast that is received by the process will get the process killed. Make your broadcast foreground and the process won't be killed! However for those using intentfilters with SCREEN_ON/OFF are out of luck as those filters creates background broadcast and get the app killed, after the broadcast is handled!
The only inconsistencies where present until users admitted there are obvious bugs, noticeably the icon remaining in the status bar, the OS listing the service as still running while the process hosting it is nowhere to be found, etc...
Can't agree more about Google's own apps using sync and escaping this entirely, probably on purpose. However they obviously behave much more badly than any other apps as you point out, they run even if they were never used, ever.
di...@gmail.com
Is there a way to log all broadcasts? Because my app is getting killed and I don't seem to be receiving any broadcasts, and my service is started with startForeground and runs in the same process.
km...@gmail.com
@androtu (#23): yes, a non-foreground broadcast causes process death.
This is an inconsistency in system code somewhere -- the process still has a foreground service, and this should be taken into consideration when deciding how important the process is (but is not).
I ran some tests with adding Intent.FLAG_RECEIVER_FOREGROUND to all my broadcasts, even those set in AlarmManager, and it helped somewhat, but there are still scenarios causing unexpected process kill:
- Broadcasts sent by the system (e.g. ConnectivityManager, etc.) which I can't control
- This is a weird one: updating a home screen widget (!!!)
This is an inconsistency in system code somewhere -- the process still has a foreground service, and this should be taken into consideration when deciding how important the process is (but is not).
I ran some tests with adding Intent.FLAG_RECEIVER_FOREGROUND to all my broadcasts, even those set in AlarmManager, and it helped somewhat, but there are still scenarios causing unexpected process kill:
- Broadcasts sent by the system (e.g. ConnectivityManager, etc.) which I can't control
- This is a weird one: updating a home screen widget (!!!)
cc...@gmail.com
Another weird one is receiving SCREEN_ON/SCREEN_OFF events, many
IntentFilter can cause this.
To cope with this, when my service receives a onRemoveTask keeps a flag
about it, then on every onReceive of such broadcast receiver I check for
that flag and set an alarm to auto-restart the service.
Looking at the source code it seems (hopefully) this non-foreground
broadcast only affect swiped-away task apps, but the OS will not kill the
apps with foreground services.
That's a real mess, and this buggy version has been out there for month now
and is spreading like a virus!
What do we do once it's fixed in the OS? Keep those dirty work-around for
API 19 only hoping for the best? And what if they release 4.4.3 under API19,
those dirty workaround are just wasting CPU cycles and may cause more harm
than good in the end.
-----Message d'origine-----
De�: android@googlecode.com [mailto:android@googlecode.com]
Envoy�: jeudi 13 mars 2014 12:02
��: ccounotte@gmail.com
Objet�: Re:
permanently kills app (like force-stop) even though it's running background
services!
IntentFilter can cause this.
To cope with this, when my service receives a onRemoveTask keeps a flag
about it, then on every onReceive of such broadcast receiver I check for
that flag and set an alarm to auto-restart the service.
Looking at the source code it seems (hopefully) this non-foreground
broadcast only affect swiped-away task apps, but the OS will not kill the
apps with foreground services.
That's a real mess, and this buggy version has been out there for month now
and is spreading like a virus!
What do we do once it's fixed in the OS? Keep those dirty work-around for
API 19 only hoping for the best? And what if they release 4.4.3 under API19,
those dirty workaround are just wasting CPU cycles and may cause more harm
than good in the end.
-----Message d'origine-----
De�: android@googlecode.com [mailto:android@googlecode.com]
Envoy�: jeudi 13 mars 2014 12:02
��: ccounotte@gmail.com
Objet�: Re:
permanently kills app (like force-stop) even though it's running background
services!
en...@google.com
co...@gmail.com
me...@gmail.com
I think I'm having the same issue except my reproduction of the bug is much easier. I'm seeing this on a Nexus 5 running Android 5.0.1.
Here is my StackOverflow question with details on how to reproduce this.
http://stackoverflow.com/questions/29221149/foreground-service-getting-killed-when-pressing-home-button
Here is my StackOverflow question with details on how to reproduce this.
lj...@gmail.com
i found perfect workround
service killed because no activity in that process had binded it，i think it's a android bug.now you can do like below:
start an empty activity which run in service process, do bindservice then finish immediately.now your service process won't killed when user swipe away your app
class NannyActivity extends Activity {
public void onCreate(Bundle savedInstanceState) {
//must run in servce process,must bind that service
bindservice(xxxxx);
finish();
}
}
service killed because no activity in that process had binded it，i think it's a android bug.now you can do like below:
start an empty activity which run in service process, do bindservice then finish immediately.now your service process won't killed when user swipe away your app
class NannyActivity extends Activity {
public void onCreate(Bundle savedInstanceState) {
//must run in servce process,must bind that service
bindservice(xxxxx);
finish();
}
}
mi...@naprvyraz.sk
#23, #26: Do you have a code example for this? I'm able to reproduce it with the PendingIntent way but not with plain BroadcastReceiver + ACTION_SCREEN_{ON,OFF}. If possible, please include Android version, too.
Description
Steps to reproduce:
- Take any app that have a UI and runs a background service (with stopWithTask="false").
- Open the UI, go back to launcher, then remove the task/app from recent task list
What happens:
- App is permanently terminated along with any of its services.
What I believe is the correct behavior:
- App UI is terminated, service remains functional.
On Android 4.0 up-to Android 4.3, the "correct" behavior can be verified, eg the app UI is terminated, services keep running (or restarted?).
IMO, the following documentation confirms the "correct" behavior I expect:
public static final int stopWithTask
If set to true, this service with be automatically stopped when the user remove a task rooted in an activity owned by the application. The default is false.
public void onTaskRemoved (Intent rootIntent)
This is called if the service is currently running and the user has removed a task that comes from the service's application. If you have set ServiceInfo.FLAG_STOP_WITH_TASK then you will not receive this callback; instead, the service will simply be stopped.
Since Android 4.4, IMO the stopWithTask flag is now completely ineffective. Or is this intentional?
I find this new behavior highly confusing for end-users: the recent task list is turned into a task killer force-stopping apps, but is not able to stop apps having started on boot except if end-user first starts the apps he/she wants to kill! Can't be any worse IMO.
So now we have 2 ways of force-stopping apps depending on whether we started them or not, from the recent task list or from the Applications, Installed Apps, Force-Stop button. Even more confusing IMO.