Shared publicly  - 
Now that 4.3 is out, something worth mentioning --

We discovered that there have started to appear applications abusing the Service.startForeground() API -- which is, -- to make their application unkillable without the user knowing.

They were doing this by creating a carefully malformed Notification object that resulted in the notification manager not posting the notification, even though the activity manager thought things were fine and so allowed the service to go in the foreground state.

Originally we were going to solve this by just being better at detecting this kind of malformed notification, and crashing the app like we do on other bad notifications.  Unfortunately, there are too many applications doing this for that to be a viable approach.

Instead, what we ultimately did in 4.3 is have the system put up its own notification when it detects this so that the user is aware of what is going on and the app doesn't have incentive any more to do this.

If you have an application that has been doing this, you'll want to update your app to stop doing it, so your users don't see the less-than-optimal generic system notification it creates for you.
Mohammad Adib's profile photoAlex Cohn's profile photoGioacchino Guarino's profile photoKrikor Arakelian's profile photo
Fascinating. Why would you want to be unkillable? To snoop? That's the only reason I can think of but there are likely more.
Fantastic, +TuneIn seems to be an offender, a notification popped up about their app which sent me to the app details screen, I promptly force stopped it. Too bad I paid for the premium version or I would have uninstalled it

Also, just to satisfy my curiosity, can give a bit more detail about how the notification was malformed (or a link to the commit which shows the new behaviour if you don't want to go into too much detail)
I found out about this the day I installed Android 4.3, and I thought it was a feature to save battery life at first:
Soon after I found the real intention behind it I have to say: You do an awesome job on protecting Android and its users! :-)
+TuneIn, I believe you really should be working on a fix, and fast!

(Oh, and in the end it actually might lead to improved battery life after all - namely force closing bad apps…)
Today I finally installed the Simpsons game. A few minutes ago I got a notification I wasn't expecting with a message of Homer finished doing something. I thought I've finished the app, but... It looks like it remained in the foreground without me knowing it. And besides that being bad, it is an abuse.
+Matthew Warren -one correct use case for startForeground is playing music in the background (where the user would instantly know if your music playing service was killed). Of course, most music players should have a notification (with controls, now playing information, etc) anyways...
This explained those +TuneIn notifications I'm getting since I upgraded, thanks guys....
This is a welcome feature!
That explains the silliness that is Audible (I get a whopping three notifications...)
Glad to see this news... but this just makes it more critical that Audible fix their silly unkillable service.
+Matthew Warren I haven't seen anything trying to use this maliciously.  Mostly it seems to be applications trying to make themselves work like a desktop application, instead of a mobile application.  For example this is often associated with a "quit" option buried inside the app somewhere.

+Ian Lake Yeah there is nothing at all wrong with using startForeground(), when you are doing it with an actual notification. :)  The point of this design is that the only reason for you to be in the foreground is that you are doing something that the user is actively aware of, so you also should have a notification to go along with it for them to control what you are doing.  Good examples of this would be playing music, maps navigation, recording your movements like with MyTracks, etc.
That API doesn't seem to specify proper use vs abuse...
Android Developer Support actually sent a short but clear email to at least some developers about this in early May . "It appears that your app is starting foreground services without providing adequate ongoing notifications to be shown to the user." . Though it didn't mention 4.3, the timing certainly made it clear to me at least to fix it before I/O (which I did).

+James Mason The abuse was not showing a notification while running as a foreground service. This was possible because startForeground just checked for a Notification, not a valid one, and the actual act of displaying the Notification realized it was invalid and didn't bother displaying it while also not demoting the service's priority back to background. Using startForeground to leave a game running in the  background probably isn't strictly speaking abuse, but the users are going to revolt because of the visibility of the notification. Using it for a music player is unlikely to cause user revolt.
+James Mason As pointed out by Dianne it's no real abuse. But the users should always be aware of applications that are keeping a foreground service running all the time by showing them a notification. :)
How easy is it to create a malformed notification request?  Will the available API do it, or do you have to go to unusual lengths?

Depending on how difficult it is to do this, I'd be more inclined to assume malignant intent on the part of the app author(s).
While this may be good for some apps (like tunein), take an app like tasker, which needs to run in background and thus has to display a notification, cluttering the notification drawer.

Before, I was able to select the "hide notifications" button and tasker would run without displaying a notification. However, in 4.3 even after selecting hide-notifications the notification remains. Same for apps like llama, smart wifi toggler, etc.

EDIT: The best solution would be to display this notification for apps by default, but have deselecting the "show notification" tickbox in settings remove this notification.
+Leo L. Schwab It's trivial. The Notification Manager will reject any notification without a small icon (i.e., Notification.icon == 0). So prior to 4.3, using such a notification with startForeground() will fail to post the notification, but your service would still go into foreground mode.

Mother of God... That's why my LightFlow was fucked up! Those bastards shall pay.
+Matthew Warren Launchers do it. I'm no dev...but I imagine a launcher is something you want to never get killed.
+Aaron Bruce As I understand, the only way you could do this is to deliberately send a malformed notification in the API. Launchers don't get killed, their activity works a bit differently from normal application activities.
+Ronald Kinard Well then I guess the go launcher devs did something weird. I got the notification on 4.3 for that particular launcher.
Why not simply refuse to promote the service to the foreground if you don't get a proper Notification? If the requirement of the API is to send a Notification object to the system and it doesn't then failure to promote would be reasonable. At that point it's up to the developer to fix their broken service. 
Except it doesn't happen only for malformed notifications. Even if you try to hide notifications (by unticking the show notification box) on an application that properly provides notifications for foreground (tasker, for example) the notifications show anyway.
+Christopher Morris As she said, they don't want to just break things and leave it up to the devs because it would break WAY too many apps. If they just went and changed it so that didn't work anymore, a LOT of apps on 4.3 would just suddenly get killed more frequently, and nobody would know what was going on.
I reckon the Pioneer Appradio app does this too. I've killed it in more ways than Sean Bean and it still comes back after a minute or two. 
Rule #1 "Don't fight the framework". Eventually the workaround you use will be discovered and closed. Then you'll have to invest new resources in fixing what you intentionally broke.
Now if only there was a way to make users aware of apps that "forget" to stop their sticky services. :) Service trashing or whatever you want to call it seems to really hurt performance on the low-end devices. 
+Todor Kolev My older relatives are unlikely to look there and even if they did they don't know enough of how computers or Android works to be able to tell if an app is there for a reason or if it is badly designed and is causing problems. 
+TuneIn you have been discovered! Remove the start foreground process with transparent notification, your work around not work anymore on 4.3...finally we saw what you did there... 
exDialer does this when you select the "keep in memory" option.
So what's the proper way to do this now (stop apps you want from being killed yet never show a notification)? Is it possible?

There are several utility/monitor type apps that the user would want never killed. But to have a persistent notification gets in the way of 'normal' notifications (aesthetically) and makes the status bar and notification shade look very busy. Would it not be better to allow the user to set that persistent notifications don't show for selected apps of their choosing?

The setting in the apps screen to stop notifications from an app doesn't seem to work in this case :-( Is that a bug?
+Johan Appelgren  +Dianne Hackborn  Not my app, but say something like this:

I know it's running, I don't want it killed. I also don't want my status bar and notification shade cluttered with it permanently. I don't see how doing that adds value for me/the user - it just gets in the way. If I want to see what's running there's already a feature (to see running apps in the app list).

I actually don't mind the notification when the app starts, but I should be able to remove until it re-starts after an reboot or after I've killed the app myself. The removable notification should be a "warning" that the  app will continue to run and consume resources until I, the user, stop it.
+John Seymour Since it draws on top of all other apps is it really killed (and restarted) that frequently without the notification? The only way I guess would be if the user could opt to hide the notification, but it'd probably clutter and confuse the UI for a rareish edge case. 
hang the offenders.
+Johan Appelgren  Yes, I would be happy with being able to hide the persistent notification as I suggested above. To make it non-persistent :-)

Apps like this could have a system enforced notification when they start, but it should be possible for the user to clear it nonetheless. Or there should be a method for the app to (legitimately) hide the notification and still be put in a state where it doesn't get killed.
+Pranav Prakash +1, same experience and wish here. The notification tray gets really unusable with many constant notifications in it, but there are many apps that needs to have a notification to do what they do. TuneIn has 4.5 stars at 300k ratings and the Android team decides they are doing something wrong by not cluttering up our trays, lol. Tasker is similarly highly rated.
As for things like Tasker, I use Automagic Premium. It has an "Ongoing Task" in the notification bar all the time. 

It doesn't clutter, in fact I like having it there. I can click on it and go to my lists of tasks to edit them. It's great. 
+Johan Appelgren But then the status bar will be overcrowded with notifications. And what's the point of notifying the user if they don't know if the service needs to run or not? E.g. a clock widget that needs a service to register a broadcast receiver for the clock tick message. That service needs to be sticky because if killed once it needs to restart or else the user will have a dead clock on the home screen. How will the system know if the service finished it's job or not? What benefit will the user get from having a notification that his clock if alive?

If the user has so little knowledge of the Android system, it's likely they will have a task killer installed and then the unneeded running services will be the least of their problems ;)
The irony of all this from a user experience point of view is the "randomness" with which apps will seem to stop working because they're getting killed with no warning to the user. It depends on the OS, amount of free RAM etc. I realize this is a problem for the developer to fix.

But we're here discussing that the user must be permanently informed of something that will not affect them moving forward (the app won't get killed). The notification is kinda "By the way, this app will continue to run consuming resources". Why do I need these messages in my face all the time as a persistent notification for each app that does this?

More useful might actually be a notification "Hey, this app was stopped by the OS because you're running too many apps at the moment. So whatever that app was doing for you, it's now stopped!"
+John Seymour And the notification will randomly go away when the system restarts the sticky service? Hmm....
Forcing the foreground service to show a notification is really a bad design which goes against the users.

It may work for some use-cases but definitely does not work for my apps: Dock4Droid, Twilight and PowerLine. In this case the service needs to be foreground otherwise the whole concept would not work, the service consumes barely no resources and has barely any effect on battery, and even without the notification the user is aware the services are running as in all 3 cases the apps show something on the screen when running. 

So with 4.3 I will be again (and I'm already) flooded with emails from the users who ask me to hide the redundant notification which clutters their status bar! Great job Android team! 
The real case where apps needs foreground service are not that much

Actually apps don't need it, they only abuse of unnecessary foreground service.

Lots apps do things in background without use a persistent foreground service.

I think that's the scope of the new behavior, limit foreground service because there are better way. 
+Todor Kolev Fair point. But I'm still on the side of use of the notification shade and status bar to show dynamic information to the user.

Maybe we need two notification interfaces - one for clearable notifications, and the other for persistent/static/'status' notifications. The current system is becoming too overloaded with persistent notifications and is becoming less useful all the time....

How about moving persistent notifications to the panel with the settings and toggles (and removing them from the status bar)?
+Petr Nálevka If you explain to the users that the notification is needed by the OS I don't think they will be that harsh. You shouldn't have used the workaround in the first place though.
you can always disable notifications completely in the app settings
+Petr Nálevka did you tried without foreground service? Are you sure your app get killed by the os if the user is using it ? You can handle that, nova launcher for example works fine without foreground service
+Cristian Zomparelli Yes, without foreground service the overlay views used in those app will start disappear, the principle of those apps is the views shall always be available to the users...
+Dianne Hackborn  While we're on the topic of services, the following Google apps have (unnecessary) services running continuously: Google Voice (2), Google Play Music (this is particularly bad, no reason it should be leaving it's playback service running all the time), Google+, and Google Wallet.
+Petr Nálevka Is that a bad thing if memory pressure is high? If the app listens for screen on and other relevant intents it will at least be visible when the user turns the screen on and any monitored data changes. 
+Johan Appelgren thanks for pointing this out. This is in fact another reason why you need a foreground service. If you need to update your views just after SCREEN_ON. You cannot register a SCREEN_ON receiver in you manifest, but instead need to create it in your service. If your service is not guaranteed to run you can miss the screen on and the user will see outdated information.
You can always use my app to uninstall these offenders. Just search batch uninstaller to stop these culprits lol
+Aaron Bruce Launchers should not do this.  Does this stock launcher do this?  No it does not.  It does not need to.  The platform keeps track of what process is running the current launcher and tries harder to keep it in RAM than other processes.  By abusing startForeground() with launchers, all you are doing is making the platform not work how it is supposed to, so it can't get rid of your process in cases where it really needs to in order to provider a better user experience.  (For example on a low-end device showing a heavy web page, given how large launchers tend to be it may really need to expunge that process in order to better support the current user experience in the browser.)
+Dianne Hackborn What do you consider to be a low-end device? After a day or so uptime my Galaxy Nexus almost always kills the launcher when I use almost any app and I try really hard to avoid having service abusing apps installed, Flickr is the only one atm. 
I'm curious how this was discovered? Do 'you' have a system for gathering metrics for app behaviour
+Simon Weizman I don't see how LightFlow could do its intended job without running in the background other than eventually adopting the new Notification Listener service..
+Mathew Pinard The old hack LightFlow used I understand is running as an accessibility service, which keeps you running all the time without a notification.  The new notification listener API also keeps you running all the time without a notification.  As do live wallpapers and IMEs.
Audible AND TuneIn for me. Shame on the "Battery Wasters"!
Background services? What? Someone needs to reread what +Dianne Hackborn wrote. So much misinformation and so many misunderstandings going on here. 
+Petr Nálevka So set "PRIORITY_MIN" on your notifications, that would remove the icon from the status bar and push them all the way to the bottom below important ones, making it a non-issue.

The only potential pitfall going forward is Samsung, which has so far opted to stick with the pre-Jelly Bean way of doing things by keeping around their dedicated "Ongoing" section which still promotes that type above the rest in the notification shade of 4.1+ Touchwiz devices.

That's where your gnashing of teeth should be focused because that not changing for 4.3 is whats really going to put you between a rock and a hard place. 

Hopefully the Android team is doing some work behind the scenes to make Samsung drop that structure for their upcoming 4.3 builds (one could argue its their duty to do this since they're partially to blame for letting this fester for so long that it became end user expectation that they be hidden this way, resulting in there being no market pressure on Samsung for their sub-optimal  4.1+ implementation ). 
+Simon Weizman it's certainly frustrating for apps such as ours where users don't want the clutter, but they do want the notifications (the led light is classed as an ongoing notification in this case). The notification priority is set low to try and help and it doesn't need to run in the foreground.
+Dianne Hackborn Lightflow gives the option of running in the foreground or not. Usually the app will work fine without it, but if android does some cleanup work and kills it then in the time between that and it restarting any notifications come through from apps they won't get picked up. Therefore I give the users the choice of running in the foreground if they want (but having an ongoing notification, but set to a low priority). The notification listener service will help to some extent as I'll be able to resume after being killed off, but the default white led will still show from between the crash and the restart.
+David Lawerteh thanks a lot for pointing this out! In fact I was looking into this as well and did already yesterday released new PowerLine version which utilizes PRIORITY_MIN. Personally I think it is a good compromise, even I already have one feedback which asks to remove the notification also from the shades and I'm sure there will be more. Exactly as you say I'm more afraid that the notification won't hide on some environments, if it is Samsung than I'm doomed anyway as this is around half of the market.

Many thanks to everyone on this thread. I hope that with creative workarounds our concepts will survive the Android team campaign for a more "secure" and "stable" Android. We already had many issues with 4.2 changes such as: airplane mode or READ_LOGS. READ_LOGS is specially painful as it gives no way to remotely debug issues with users. For example SoundPool is now broken in 4.3 and I have no way to see what is going on without a physical 4.3 device. But this is a long story for another thread.
+Petr Nálevka You can ask your more tech savy users to enable developer options and usb debugging so they can generate an error report and send to you. 
+Johan Appelgren This is unrealistic. I'm developing Android apps for more than 3 years and during this time I have never convinced anyone (even technical people) to send a logcat generated this way. Just imagine all the steps you need to explain - and now a new step to unlock the developer mode (btw is this some internal joke in the Android team?). 

On the other hand I got hundreds of useful logs from users using the alogcat app. Even non-technical users can do this if they want their problem to get solved and we solved loads of problems this way.

I think abandoning the READ_LOGS permission is fine, but there should have been a system component with the permission to access logs which users can use to be able to easily send logs to developers. Now we face very strange firmware specific issues and we are completely helpless. We cannot afford to physically own every Android phone with a market share.
+Petr Nálevka It was just a solution/workaround if the logs that your app produces isn't enough for you to solve an issue. Not saying it is perfect. 
+Johan Appelgren thanks a lot for the proposal anyway. Unfortunately your app log is of no use when you try to solve various hardware layer issues, typically: audio, sensors, camera...and also if you target interference between apps, but sorry, I will stop commenting this as this is for a different thread.
I see others already also have expressed their concerns with this and I also want to do it.
If I understand correctly this new behavior then I will be very sad when I get 4.3 on my s4.
Because I have quite a few apps that have the option to hide the persistent notification, I guess those apps use this 'hack'? So for all of these apps I have suddenly persistent notifications? That would mean that I guess I have 2 or 3 more of those notifications permanently, that is really horrible! Why? Because president persistent notifications (ongoing) are on top in the list on my phone, so those are the first I see, if I have 3 or 4 of them I don't see anything else any more. So email, WhatsApp notifications are not immediately visible without scrolling and scrolling. I talk about touchwiz here, don't know about other skins, but then I want definitely that or the 'ongoing' are always at the bottom or they have there own section/tab in the notification bar, I really don't care much about them, they are just annoying!
+barnassey thomas +Dianne Hackborn explained in a previous comment that Android tries to keep whatever is set as the launcher harder than other processes, so you don't have to use startForeground to do it.
Maybe add in AppInfo a toggle "Allow app to run in foreground without notifications". Stuff like Audio Concert or Tasker where I want it running, I know it is running, but DON'T want it in my notification drawer.
+Dianne Hackborn  There's clearly a view here that folk don't like the current UX that's now been provided in this important area. A similar view is beginning to emerge over on the XDA site. Are you able to get this view expressed as feedback within the appropriate team(s) within Google?

I don't think there's so much concern that users should be subject to ongoing persistent notifications, so much as the manor in which they are presented reduces the value of the notification system overall.
Can someone tell Audible. I now have 3 x Audible is running notifications and not a lot of room for anything else in the notifications bar!
+John Seymour I have no problem with it so far. Seems like a good way to solve the problem. 
+Jerry Hildenbrand +Audible 
Crashing the app would probably be better. At least it would get fixed with some urgency then. I can't see Audible fixing this any time soon and I want my notifications bar back. 4 Audible notifications is too many!
great, thanks, this is really stupid. maybe have an option to permanently disable the notification in 4.3.1?
Why not add a new permission and force us devs to declare it in the manifest if we want to use this kind of service? That way, the users know and approve the use of that feature and the developers don't have to find workarounds all the time.
+Lior Iluz I don't think workarounds to a hack is Googles problem really. Apps shouldn't abuse startForeground. And adding new permissions wouldn't work in my opinion. If anything they need to be made even simpler as most don't read or understand them as it is. 
+Thomas Toft I agree workarounds are not Google's problem but they can't kill 3rd party apps services as first priority and provide us with no solution (START_STICKY isn't enough). The users hate unclear-able notifications... they mean nothing to them. What happens when you start getting 3-4 stars rating because of this? You think the user care it's a system limitation? I already received 5 emails about this from users with Nexus 4,7,10 running Android 4.3.
Ah so that's what that notification is about. The +Sonos app is also doing this. 
+Matthew Warren To use apps like Sidebar, that need to be active all the time to detect the user's swipes from the edges of the screen. Those types of apps need to always stay open.
Sidebar seems like a good example. That said, would Facebook be one of these "abusers"? Their app starts a service that doesn't get killed, yet I don't recall getting a notification about it. IMO, it seems a bit strange that the user has to withstand a notification like "Facebook is running" and can't even dismiss it. Some apps need to cache data or access the network asynchronously, even if their activities aren't running; what would be the appropriate way to handle this?
I take it back, Audible have updated and it appears they have fixed it.
This would be a great idea if the "Show Notifications" checkbox on apps actually respected what a user decided.  I don't want to see Tasker's ongoing notifications.  I uncheck "Show Notifications" for Tasker and it goes away, but in 4.3 it comes back after awhile.  I told the OS I didn't want to see it, respect my decision.
My Nexis 10 is stock. My gnex has cyanogen mod 10.2. Same problem on both.
Very weird... Tested on both Nexus 4 and old Nexus 7 (stock rooted), specifically with Tasker and it works.
Do you have run in foreground enabled?
Yeah... As always. Tested with my app (Overlays) to make sure and also works.
Maybe there needs to be some proper place for apps to register to run in that state. So they can't be set in secret and apps that really need it can do it nicely without flooding the pulldown drawer.

Something like the device administrator setting?
You need people who know how to abuse things in your test pool.
This speaks to the fact that you guys work in a vacuum.
Same thing happening with BLN Control. Uninstalling it after 4 years. Will miss it
Sounds good for user end security..
+Dianne Hackborn , as someone developing a launcher and having to deal with constant re-loads, especially on hardware <= a galaxy Nexus, what would you say is 'best practice' for elevating the launcher priority? (Assuming no background process are actually needed for launcher functionality)
I bought a new 10.1' rockchip cortax A9 processor 1550ghz based tablet a month ago(Spice MI 1010). It is 4.1JB with a huge 7600Mah LI-Po battery.As i charge it to full 100% & turn it on the battery level always drops sharply to 97% in next 10 to 12 mnts & from here onwards it gets stable.The second problem is as i turn it off after a small use of 10/15 mnts after charge (batt. level around 97% as mentioned above) & switch off & on next restart the previous usage time of 10 or 12 mnts whatever gets reset to 0 mnts while it maintains same battery level of last time when it is switch off(97% or whatever it was remains) i wanna know why battery drops sharply to 97 % after full charge in just 12 mnts & why on next restart the previous usage of 10 mnts is deleted & resets it self to 0 mnts?? Do i need to reset tab or is it normal ??..or what is remedy ???
+amit sethi
Next time buy a branded tablet, those cheap crappy ones are good at nothing. Your rom/kernel is likely bugged or the battery itself may be defective. Calibrating it might help.
Hi if rom/kernel is likely bugged then what is remedy? Battery back up is proper & growing up day by day as it's only 1.5 months old tab..thanks for reply..& yes i  calibrated it which give me sm more good back up as i feel.
+amit sethi Unfortunately non-approved devices often carry such problems due to poor work done by whoever built the rom. No one except the manufacturer can fix that since the kernel sources were probably not made public (hence no one can recompile it with the fixes implemented). In the end it's up to your manufacturer to issue an update, else nothing can be done.

If the problem is application-based then it's likely a partial wakelock caused by some built-in resource bloatware app. Use better battery stats to find out what's killing the battery so fast.
sorry i'm new to this place :D
I'd propose to have a user action to stack all sticky notifications into one box. When several foreground services (e.g. "USB Connected", and "USB debugging connected", and "Connected as USB Storage") run together, they fill all screen space on my 7" tablet.
Well google+ cant be killed matter how many times I shut it off i settings it turns itself back on.....WTF!!!!!

Ok, I have a question - I have the motoactv app, which(obviously!) is responsible for the connection between my phone and my motoactv watch. The problem is, that I get persistent notification for the app running. I know it runs, it is supposed to! But also it gives me this little blue icon to know that my watch is connected. When I uncheck Show notification this icon is gone as well...So for me it's 2 icons or no icons at all... I just want to see the little blue icon to know the watch is connected,  without seeing that the app itself is running, I know that...
Add a comment...