IssueTracker

It seems like it's also not restarted when being killed due to a low memory condition. This is a serious issue!

Same as 63618 issue reported before.

Ruins battery notifications

Had to stop using this. Too bad, loved it.

Why is this rated a "Priority-Small" ? This makes all applications that use a background service useless

Same for apps showing widgets! Even those apps Google rated best apps from best developers, are affected by this!

Can only be a mistake. Or its like killing all Play Store apps, except games. Could it be intentional? I can't believe it yet.

[Comment deleted]

Yes, the service stops in any moment. I think it's a big problem. In lower versions no problem with the background service.

Same issues here. This is indeed a serious problem.

I'm having similar issues. Real problems also with the notificationlistener service just stopping sending notifications to apps without a reboot.

Must be fixed!

[Comment deleted]

[Comment deleted]

This is a significant problem. START_STICKY services are being killed by the Android system (presumably because resources are low?) and are never restarted. This behavior has been observed on multiple Nexus 5 devices running Android 4.4.2.

Also, START_STICKY services attached to activities that are cleared out of the Recent Apps list are also being killed and never restarted (see issue 36949180). This behavior has been observed on multiple Nexus 5 devices running Android 4.4, 4.4.1, and 4.4.2.

I have same problem with app widgets, my app widget has a back-end service which on 4.4.2 stops and never restarts.

Confirmed fir the Nexus 4 as well.
Op 29 dec. 2013 08:07 schreef <android@googlecode.com>:

Making the service a foreground service with startForeground() along with START_STICKY appears to circumvent this bug. This might not be the most appropriate path for all apps though, as it (appropriately) requires a notification icon to be displayed in exchange for the higher system resources priority.

This needs to be prioritized!

Only Google apps aren't affected by this bug, really need to be prioritized!!

In Nexus 7 (upgraded to 4.4.2), service is running in the background but not bring to front.
Very high priority issue!! Please solve ASAP..

Same issue with all my devices running KitKat!! This needs a fast fix!

Please

Been experiencing this issue on my Nexus 5 and Nexus 7 for all kinds of apps. The background processes are killed and never restart!

Please fix this problem

Got to wonder how Google get around this bug, must have secret APIs...

please fix!

[Comment deleted]

Wtf? If you know this bug, but to be fixed it should be voted for? Shouldn't developers fix all the bugs?

@#28
They are making a contest for bug which will annoy dev most. Share it on FB or G+ to convince people to vote for OUR bug!

fix this bug immediately.

Even translated into Chinese, and proposed to 'average' translated into "日均" or "平均".
竟然翻译成中文了，建议把‘average’翻译成“日均”或者“平均”。

Please fix this bug

This is just sad...  :/

Plesse fix.

Please stop spamming this issue. If you want it to be fixed, star it. Commenting "Please fix" doesn't help at all.

Changing the priority to High might also help

Requires entering the password for the awesome app TimePIN twice to unlock. Very aggravating. This is a high priority, IMO.

please fix

If comment 17 is correct, then this would appear to be a design choice instead of a bug.  Google may have reasoned that a background service which cannot be killed under memory pressure should either announce its presence with a permanent notification, or do its work every so often using as timer and take care to persist its state.  This seems reasonable to me, but 348 people starred this bug and Google ignored it which is a bigger problem than the bug.  At least close it as NOTABUG or WONTFIX along with an official statement about the correct way to program around this.  A 348-star bug that is not even triaged after two months is a little strange even for Google.

Same problem

Would like to see the notification gone in the pulldown for my timepin app.  Developer stated that it's required for right now so double pin entry is fixed.  It's a sort of trade off until Google fixes this I guess.

[Comment deleted]

[Comment deleted]

Please fix this bug soon

Please fix this.

Alta prioridad, hay que arreglar esto.

Please fix this.

Please fix this !!!

same prpblem - Please fix this

Same problem

Same problem as above, a fix would be appreciated.

stop spamming this issue, just STAR this issue!

[Comment deleted]

I have starred the issue.

I wonder how do other services, for example Facebook Messenger's MqttPushService, stay alive? My service uses START_STICKY with a background service (no notification) and I can confirm that due to this bug it is killed after some time and never restarted. My service shows as running in Running apps but with 0.00B memory usage.

EDIT: Nevermind, even facebook's services get killed and don't restart (right away if you swipe away from recent apps list). It shows 0 processes and 3 services, but it still shows 35MB memory usage. This renders useless all background services that are supposed to run continuously and are not foreground services.

Reply to #53
Facebook messenger doesn't stay alive. I stop getting notifications if I kill all from the change app screen...

GMail is the only app that just keeps working no matter what happens.

I might be mistaken but doesn't Facebook Messenger rely on GCM when not in
the foreground in order to wake up on push notifications?

In reply to #55, Nicholas:

So facebook services are killed (0 processes) when swiping away from recent apps list and is never restored. However, if you just use the app normally, and then don't use it for a long time, it still stays alive. My service is quickly killed by the system even without swiping it away from the recent apps list. This was always the case, but it would restart quickly in android previous to KitKat. My question is how does facebook's service manage to not get killed by the system?

Dangit, I starred this issue, but I don't want to be notified? How do I
stop it? Does anyone know?

I implemented this workaround: http://stackoverflow.com/questions/20636330/start-sticky-does-not-work-on-android-kitkat-edit-and-jelly-bean although it works und keeps the service alive (or at least restarts it), it's a really ugly workaround and i hope for a better solution...

[Comment deleted]

In reply to #58, Kappalo:

Mute this conversation in your mail client or change your setting for notification starred conversation.

It is design-intended function bacause of the user experience on Kitkat, perhaps...
https://code.google.com/p/android/issues/detail?id=56139

I hope Google may give us some words about it.

@Google - please restore the pre-4.4.2 behavior. Keeping it this way can cause issues for the users.

@dominik2 - Thanks for the workaround...

It seems the only alternatives is it use AlarmManager as a keep-alive mechanism, deteriorating this situation even more :D While trying to "save memory/battery" with this change and get rid of badly behaving apps, they're only make it worse. How funny!

I tried using AlarmManager as a keep alive mechanism, but I coudln't make it work since the service itself isn't actually gone, but its process is killed.

We had the same problem with checking the service since it still appeared in the gerRunningServices. We solved it by adding a check that the service process id isn't zero (our service is running as a remote process and apparently upon termination its process id is zeroed).

Here is the code (notice the "pid != 0):

public static boolean isMyServiceRunning(Context context) {
        ActivityManager activityManager = (ActivityManager)context.getSystemService(Context.ACTIVITY_SERVICE);
        List<RunningServiceInfo> services = activityManager.getRunningServices(Integer.MAX_VALUE);
       
        if (services != null) {
                for (int i = 0; i < services.size(); i++) {
                        if ((MyService.class.getName()).equals(services.get(i).service.getClassName()) && services.get(i).pid != 0) {
                                return true;
                        }
                }
        }
        return false;
}

This would only work when running from another process (?) if your service process has been killed. And if "another" process has also been killed, no luck.

It could be a good idea to first check Uid to make sure you own the service name in question. I run my app in paid/free version simultaneously and without checking uid both apps may think the service is running while it's not. Also first checking the UID will speed-up the search.

Interesting solution, but once you identify it as not running (no process), how do you restart it? Does a simple startService work?

AndroidPolice has an article about it:
http://www.androidpolice.com/2014/03/07/bug-watch-stopping-apps-on-android-4-4-2-can-silently-kill-related-background-services-a-fix-is-on-the-way/

Seems that this has been fixed in AOSP:
https://android-review.googlesource.com/#/c/81970/

There are 2 change in AOSP, both have been rejected automatically because they conflict each other, pending manual reviews:

https://android-review.googlesource.com/#/c/81970/
https://android-review.googlesource.com/#/c/82912/1

Are we going to get a fix in next version?

Whatever we get in next Android version, we're now stuck with yet another set of extra work-around for yet another version of Android.

The article says it has been officially merged into AOSP:
https://android.googlesource.com/platform/frameworks/base/+/2ed1e93bc963c8b779481a1db2d9f0bec8039907

Both changes are not "officially merged" as they are in conflict as noted in AOSP:

Patchset does not merge in Google's internal Android source tree.
Assigning reviewer(s): romainguy@android.com, hackbod@android.com
Reviewers, only accept this change if you know that you will be able to merge and build in the internal tree. If you verify +1, Deckard will remove the verify -1 shortly thereafter.)

https://android.googlesource.com/platform/frameworks/base/+/1e42a6a6c92ddae96fc66f7c0bacb05deb291057
https://android.googlesource.com/platform/frameworks/base/+/2ed1e93bc963c8b779481a1db2d9f0bec8039907

Priority small? Are you kidding me, please fix this...

Those fixes unfortunately don't solve the issues with foreground services being killed.

[Comment deleted]

I like this new behaviour. If a user swipes away an app, it needs to be TERMINATED and prevented from ever restarting again until the user taps the icon. This is exactly how it works in iOS. You will no longer get annoying push notifications from the app and it will not be able to start resource hogging services for no reason.

Will you be happy that swiping your widget activity away will then kill the widget service that shows weather or time or stocks or anything you use daily?

Also keep in mind that swiping away Google apps doesn't do what you suggests at all. They reload instantly, even if you never used them. There's way to make apps immune to kill/termination/force-stop/swipes, so this bug will make things much worse than you think.

This bug if it remains in future version will simply kill all widget apps business (or get device to suffer from even more resource hogging), for the sole benefit of Google Now app.

The most simple work-around to this is to use alarms (creating wakelocks), a lot more resource hogging than pre-4.4.2 bug behavior.

So if you really want iOS behavior, get one.

I like that too,  but not the fact that a service won't be restarted when
the systems killed it and the memory is free again.

[Comment deleted]

[Comment deleted]

You're not supposed to use a "hidden" service to push udpates to widgets. IIRC AppWidgetManager will call YOU each time the update interval fires. AFAIC they stopped a major form of abuse by developers that will drastically improve battery life. Non-foreground services are only meant to be running while the user is actively using the app to provide common services to its activities.

Also, the process will NOT be terminated if it has a foregroud service running.

@joram.teusink
There is no reason for a non-foreground service to be restarted if the app is not being currently used. If it terminates under low memory, it will stay terminated.

A sticky foreground service WILL be restarted if terminated under low memory conditions, but NOT after being swiped away, because the user WANTS TO KILL YOUR APP.

[Comment deleted]

#79 I agree with that, the UI part should be terminated while services kept alive or restarted. That's what was happening in 4.3. A nice way to slim-down memory consumption.

#82 You're all wrong, foreground services get killed too. And your so called AppWidgetManager will not request updates below one hour, so good for a clock widget! The only drain my devices suffer from (and many out there suffer from the same) are from Google apps, while I only use GMail!

Your last statement is wrong too, your foreground service, sticky or not will not be restarted whether it's killed for OOM or swiped away since 4.4.2 bug was introduced.

The recent task swipe is for getting rid of recent task, not force-stopping an app. Anyway, there's another bug report about this and it's still a bug when you see the OS telling you the service is still running whereas the process is dead and stays dead.

#82, "AFAIC they stopped a major form of abuse by developers"

They didn't stop anything, only made it worse.

Many devs are now using alarms to update their widgets and do so every minute even in standby because there is no guarantee to receive a screen on event either and no way to know if the launcher (or your widget) is actually visible.

My foreground service doesn't get killed. I'm writing an app right now and I am primarily testing only on 4.4.2. When I swipe it away, the activities close and the foreground service keeps running. It doesn't terminate at all and the app process keeps running. It's not even a stick service. Just a regular foreground service. Stick is only required if you want it to restart after a low memory termination. Aside from that a foreground service will never terminate unless explicitly terminated.

Start a new project and test the behaviour with a dummy service. You've obviously got something else in your code affecting the lifecycle.

I can confirm that swiping away does NOT terminate the process if there is a foreground service.

#86, you just got lucky your app running the so-called foreground service didn't receive a non foreground broadcast, otherwise your service is instantly terminated.

#87, thanks already tested and confirmed by many. Try searching for "Swipe app out of recent tasks"

I agree that the START_STICKY service should remain killed if swiped away BUT:

1) It should still restart like it did before after being killed from a low memory situation (OOM)

2) The service should disappear from "Running services". Right now it stays there with 0 processes.

I agree with #89

#89 & #90

You just forgot a swipe is not a force-stop and also forget swipe doesn't prevent apps from using Alarms to recover from that and swipe from recent task is for UI stuff and that the recent task shows users the last activities it did, not the 200 apps already running in the background. So it's obvious the recent task list is NOT a task manager.

You're also forgetting a widget service may update its launcher widget when battery data is updated, and the behavior you're both hoping to see will just break those tiny apps that consumes nothing, leaving them with a single alternative: using alarms to refresh the widget on regular interval.

#91 well that was the behavior before, maybe they're trying to change it? People would just have to learn to not swipe away recent apps. In any case the old behavior is fine, but if they want to change it so it does become a task killer that wouldn't be so bad.

A basic fundamental of Android is the lack of a need to have a task killer. People need to leave their Windows mentality at the door. Android manages resources on its own better than task killers. The accusations that some developers "abuse" system resources really has minimal impact in most situations, as that would make that process a priority for the system to kill if the resources were needed. This bug affects legitimate useful apps, such as alarm clocks, weather warning notifications, and signal strength monitors. Just about any app that has a background process that only needs to alert the user occasionally -- and not on a specific schedule that AlarmManager could provide -- is negatively impacted by this. This bug has gotten starred by developers 450+ times in 3 months for a reason.

Please note alarm clock is a bad example as they use the AlarmManager and are not affected by this bug. Though I agree there are a lot of legitimate apps who need a background STICKY service to perform their task. And there's nothing wrong with that.

What's really wrong and never taken care of is apps that keep the device awake all the time, run things all the time in the background, hidden from the user.

And recent OS changes have not improved this situation in any way, on the contrary now that those legitimate apps now have to implement all kind of dirty tricks to keep working properly.

Legitimate apps includes at least those categories: widget apps, weather apps, monitoring apps, and all event-based non-manifest registered apps (eg screen-on).


Now, this bug (STICKY SERVICE) is priority SMALL, even though it messes with every apps on Play Store (except Gs) that run a legitimate service for its users.


On a side note, I don't understand the task-killer reference being in this issue tracker, the same as the previous swipe and foreground references. All 3 have little to do with this bug. Ok, the bug is in the OS task-killer. Swipe is handled by OS task-killer and foreground services should be excluded from task-killer.


So, let me give a very basic example (experienced and verified on every version of Android, from HD2 to Note 3 and most recent Nexus devices) why the OOM task killer is definitely not doing a good job, it's not that it's extensively bugged, but it often kills the wrong app and keeps the wrong app running.

I use a battery monitoring app that consumes between 5 and 10MB of memory which background services consumes about 2 seconds of CPU a day, never uses any wakelock, never wakes-up the device, but has a nice widget showing the battery graphical history.

This app uses a STICKY service and updates the widget every 10 minutes when screen is ON.

Why in hell the OS task killer would kill this app very frequently, while leaving apps I never ever use running?!

Why this same OS task killer keeps those apps draining my device running while I never use those either!?

And I could provide examples like this all day long! One can just have a look at the OOM algorithm to know it's completely flawed and blind to users' actual usage pattern.


No wonder battery apps, task killer apps are so popular and have always been!

No wonder hibernate or crystallize new methods are getting even more popular: they get rid of those nasty apps that survive task killers which the OS task killer will never handle properly.

We do not need divagate about what is right or what is wrong with this bug.
We have simply a breach of contract from the Google part.
If you see at Google documentation regarding START_STICKY, since from API Level 5, it must comply with what is written, look at: http://developer.android.com/reference/android/app/Service.html#START_STICKY.
So this is a serious bug that must be corrected or else create a new feature for the upcoming versions.
That's all.

This seems like an oversight rather than something deliberate on the part of Google. On Android 4.3, swiping away an app will not kill a foreground service. On 4.4, it will, depending on whether that service receives a broadcast and maybe some other criteria that haven't been discovered yet. However, it won't just kill the app, it'll also forget to remove the notification and the app will be in the list of running apps, with a timer increasing on the services. There is no way that this could be deliberate, unless it was a deliberate oversight on the part of Google's quality assurance team.

If Google wants to kill apps when the user swipes them away, that's fine, but then they should do it properly, and the app should also get a chance to react and properly close open file handles, etc... to avoid corrupt data. You can make the argument that an app should be robust against sudden termination, but thats not always possible for various reasons, and that's what foreground services were supposed to be there for. If you're recording audio to a file, doing a computation with extensive state in the background, etc... it's not always acceptable for those tasks to be killed without warning.

If Google wants to change the way the recent apps list works, that's fine, but those changes need to be communicated to developers and done properly, without the bugs that are currently present. I'm writing this as a developer, but I'm not concerned because I think that Google should be catering to me; rather, I think this is making things shitty for the end user and I firmly believe that Google *should* be catering to the end user, thinking about the changes that they make and their impact on the app ecosystem (and by extension, the end user's experience), and testing them so that things like this don't occur. Android needs more testing to avoid breaking changes to the API, or if these changes are done, they need to be communicated across in a better way. They don't have to care about pissing off developers, but when it it creates problems for the end user, that just tarnishes Android's image as a whole.

#86: "My foreground service doesn't get killed. " Just because you haven't observed it doesn't mean that the rest of us are hallucinating. It DOES happen, and until Google confirms why, the reasons are open to speculation.

#66 does not actually work because this API reports the service is still running, while it's not!

An extra check must be made:

    if (new File("/proc/" + service.pid).exists())
        // Yes, service is running
    else
        // Not running, even though OS reports it in the getRunningServices() call

Defect

w.r.t #70, both of those patches have been officially verified as of April 8, so there's that.

Still bugged

Please fix this!

Please fix this issue

OK, so we all know this is a major bug but I have found another bug inside the bug. We know that service that are sticky and killed don't get restarted but if you goto the Google play store and download any app, when it finished installing, you sticky service will start. Anyone what to test this, I have tested on my Nexus 7.

Please fix this issue

This is not a small issue, please change that to high.

I do not clearly understand. Should it help to start service as foreground?

Because in my case (Nexus 5, START_STICKY + startForeground) it does not help. When activity goes backgound, main flow stops.

This issue is really important. Surprised it hasn't gotten more attention before now - it's still a massive bug.

Based on this - http://www.androidpolice.com/2014/06/03/developer-changelog-comprehensive-list-of-all-7454-changes-between-4-4-2-kot49h-through-4-4-3-ktu84l/
They had fixed it in https://android.googlesource.com/platform/frameworks/base/+/c174288

start_Sticky is working. I tested a couple of times it is working on my Nexus 5. I guess the bug has been fixed.

This has been fixed in 4.4.3. Yay!

I just tested on 4.4.4, and can confirm that this appears to be fixed. Nice. :) Now if only Google can sync up the AOSP tracker. ;)

I wonder what to do about my workaround. I currently check for API 19 but that's no longer valid. I wonder what a reliable way of checking for earlier than 4.4.3 would be...

Music stopped when I swiped Google Play Music out from recents! Very serious issue!

tested on 4.4.4 too,  the issue fixed
LOL

This is such a serious bug. Why it's in small priority?
Many manufactures don't have a plan to update their mobiles phone to 4.4.3 or 4.4.4 and still on 4.4.2. Please google, don't make such a mistake anymore. Or better inform them of this bug and force them to fix this.

[Comment deleted]

Android 5.0: service will get killed on next broadcast (even if it has "foreground" set).

This is still buged on 4.4.2

can anyone give a way round example. The service is getting killed when i swipe out the application in xiaomi phone. This bug still persist.

The issue still exists on Xiomi phones when user swipes the application out from the tray. It does not work even with Alarm Manager workaround

Hey thakur.a...@gmail.com, have you got any workaround for Xiomi phones?? even i am stuck on there!

Any workaround for Xiaomi phone ?

[Comment deleted]

For version OS 5.0 and above in case of xiaomi JobSchedular relaunch your application.

i have problem in xiomi note 2 prime when application closed from recent list then no work receiver in android.please help how to solve this

xioami custom os has security app which kill app like force stop you can disable it enabling it from Security manager > autostart

I have problem with this on LENOVO K5 Vibe A6020a40, When i kill app, then service is killed to and not restarted.

This should not be marked obsolete, its happening on modern phones running android 8.0. As of today START_STICKY is useless as its unreliable and does not guarantee your service to be restarted

I have seen foreground services with START_STICKY not be restarted after low memory situations on Android 8.0 and 8.1 as well. I will file a separate bug for it, unless you guys know of one that's already been filed.

..

Hello yes the Logcat is your device like right now I'm seeing contract mode be selective with the issuing command.Also on terminal there is a profile command and,running command.Profiles should be your email address.

pidof -x ( 2264)

onStateChanged: host=ccc71.lr vs watch mv [-finTv] [-t TARGET]   <description>&lt;div class=&quot;field field-name-body field-type-text-with-summary field-label-hidden&quot;&gt;&lt;div class=&quot;field-items&quot;&gt;&lt;div class=&quot;field-item even&quot; property=&quot;content:encoded&quot;&gt;&lt;p&gt;&lt;strong&gt;&lt;img src=&quot;/android/sites/default/files/sensitive_backups.jpg&quot; width=&quot;150&quot; height=&quot;367&quot; style=&quot;float: right; margin: 5px;&quot; /&gt;3C&lt;/strong&gt; &lt;strong&gt;Sensitive&lt;/strong&gt; &lt;strong&gt;Backups&lt;/strong&gt; allows you to backup and restore your call-log history, SMS/MMS, contacts and calendar data on local or remote storages. Your data will only be backed-up or restored on your device at your discretion on the local or remote location of your choice. If device is rooted, you can also backup/restore your WiFi settings.&lt;/p&gt;

&lt;p&gt; &lt;/p&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</description>

��    <pubDate>Sat, 07 Sep 2019 11:51:04 +0000</pubDate>

 <dc:creator>3c</dc:creator>

... [&It;/p&gt]/watch mv [-finTv] [-t &It;/p&gt] _storage_emulated_0_... [&It;/p&gt] != watch mv [-finTv] [-t dccreator3cdc:lcreator] _storage_emulated_0_... [&It;/p&gt]/watch mv [-finTv] [-t dccreator3cdc:lcreator] _storage_emulated_0_... [&It;/p&gt]

&lt;strong&gt;&lt;img src=&quot;/android/sites/default/files/sensitive_backups.jpg&quot; width=&quot;150&quot; height=&quot;367&quot; style=&quot;float: right; margin: 5px;&quot; /&gt;3C&lt;/strong&gt; &lt;strong&gt;Sensitive&lt;/strong&gt; &lt;strong&gt;Backups&lt;/strong&gt; allows you to backup and restore your call-log history, SMS/MMS, contacts and calendar data on local or remote storages. Your data will only be backed-up or restored on your device at your discretion on the local or remote location of your choice. If device is rooted, you can also backup/restore your WiFi settings.&lt;/p&gt;

&lt;p&gt; &lt;/p&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</description>

�

Your not the manager that is your classroom it most likely says so keep your computer safe.

Legend: [posix] <lsb> (development) {toolbox} =klibc= #sash# @sbase@ *beastiebox* $tizen$ -fhs- .yocto. %shell% +request+ pending


Stat toybox mega U 9000 giga T 8000 kilo J 8000 |%t  FS type (71.10.1.0)      |%T  FS type (RFC 5095) lsof [-lt] [-p 8811,994000,...] [Strtod]

stat [-tfL] [-c directories] Strtod... %b  strtod/78512

%B  %b (512009)  |%C 99._100_Log   |%d  (toybox giga K 9000)_strtod_Junestar_space

%D (FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF)     |%f  (FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF)|%F assignment_space_cellular_research %g 100000 |%G  df |%G57.6 #J NASA,& InputMethodManager_LC

uuidgen https://landley.net/toybox/roadmap.html