Shared publicly  - 
 
Who lives and who dies? Process priorities on Android
Pro-tip by +Ian Lake

With a finite amount of memory, process death is a natural part of your app’s lifecycle. Read our blog post https://goo.gl/sQmKPq to understand the process hierarchy Android uses to determine which apps live and which die.

We’ll talk through what it means to be a foreground process, how visible processes differ, the importance of being a service process for background work, and caching in the form of background and empty processes.

#BuildBetterApps
Ensuring your #processes are in the correct category is the key to happy devices and a happy users
245
95
Paul Danyliuk's profile photoDmitry Suzdalev's profile photoIan Lake's profile photoGoran Šipić's profile photo
41 comments
Ian Lake
+
1
0
1
0
 
Just because we tell you how you can be a foreground process, doesn’t mean every app should be - be a good citizen and understand that you are running on a device with many other apps and do the right thing.
 
What if I need a background process to survive ?
 
+Jules Archinova - as mentioned in the post, both START_STICKY and START_REDELIVER_INTENT tells the system that you want your Service restarted if it is killed due to low memory.

Of course, that's no excuse to run a service continuously in the background - there's almost always a better way to do things.
 
My question was not precise enough, what if I don't want the service to be killed I the first place and prefer to have other process killed ?
And while we're at it, why Google auto restart services when killed due to low memory as there is almost always a better way to do things?
I think this is showing bad example to other developers.
Users should be able to pick what's more important to their eyes too 

Thanks for the answer
 
+Jules Archinova Programmers who develop their apps in the right way will have them not lose out by dying and restarting in response to system events.
 
+Jules Archinova - that's what startForeground() is for - making your service the highest priority. Again, explained in the blog post :)

Android restarts services because the app developers want them to. It is up to the developers to pick the right tool for the job (that's what this whole Android Development Patterns collection is about!).

You'll note as a user, you can see the running processes on recent devices in Developer Options - there's even an option to 'Report' and send feedback directly to the developer that their service is misbehaving.
 
Indeed, even already used it, but never seen improvements (looking at you Google).
Main point of my first message was that end users and developers may not share the same vision on what is important.
For example, gcm is absolute low priority to me, yet in low memory conditions it is running while I would prefer to dedicate that memory on my background backup task.
We know what happens when the developers have full power over what is important or not, they try to be the last standing application (hello Facebook)
 
+Jules Archinova​​​ sounds like really horrible idea to make 1 billion users decide which process should be granted higher priority just because couple of developers think it would be nice to have such feature. 
 
+Kata Lune We could do that the other way, allow users to flag services they don't care about and have those killed first, leave rest untouched. End user would just tell the system "I don't care about this specific service"

yes GCM is useful, no, it's not useful to the point that my file sync should be killed over it. ;) (Picking up on GCM because it was the last to annoy me, but that's not the only service that was wrongly set as "super-important-never-kill-me-plz", I will not notice if GCM gets killed, but I do notice my file sync failed when my last photos are not on my computer)
 
+Jules Archinova The majority of the time services won't be the thing that exhaust the resources or get killed - it will probably usually be apps with a GUI. This is also to make sure that the pressure stays on for developers that their apps are well developed - that they can pick up after a kill/restart cycle rather than telling their users to tell their devices that the rules don't apply to them.
 
+Jules Archinova - as explained in the article, Android is very deterministic in what it chooses to stop due to memory pressure and provides all the APIs a developer needs to make sure that their operations complete successfully even on very low memory device.
 
+Ian Lake Yes it is very deterministic on low spec device (512 mo memory, 600mhz mono core) keep google services while killing other services due to low memory. That's where you need to pick what is important yourself, and not let the developers decide, else you end up with all google services running and have a google phone instead of an android phone. With that on the table, as some devs abuse the priorities, services playing it fair never finish their tasks. Yes i need these services, but I don't need them more than others.
If all services are doing something and there's not enough memory, one of the service will have to stop, suspending it's task (meaning it will not finish on time, of course, maybe the file currently uploading will finish, but not the whole folder)

You cannot magically finish tasks for each services when there's no memory for it. Some process currently doing work will have to stop it's work to leave room, if it stop, it obviously won't continue it's work.

The article explain very well how things happens in Android's carebear land, but that's not real life, that's theoretical stuff that will probably happen when your device has not specs lower than what the guys that wrote it tough it would happen.

The article is right, it does work like that on my test high end device with 4Gb of ram, it works like a charm and services I do need running doesn't get killed. But on low end device only the most aggressive service stays, and it seems some developers are champions at keeping non critical stuff running, some of them being OEMs or Google themselves, you can report what you want it doesn't change.

+Pat Gunn And the majority of the time, the device will house more than 512 mo of memory and a 600mhz processor. Who do we need to pressure if a service gets killed, the devs of said service, or the devs of other services doing tasks you don't need right now but that has better knowledge at how android internals work to keep their service running ? How many people are required to pressure facebook to stop being a champion at keeping useless services running ? Same for Google. Guess we cannot, that's why in the end, the user should be able to have the last word : "Yes contacts sync is important to me, keep it untouched, no gcm is not important to me, you can kill it before other services".

Solution to notification abuse was to allow end user to hide application's notifications.
Solution to service abusive behavior is probably to allow end user to flag it as low priority and get it killed first instead of last.
 
+Jules Archinova - you'll be happy to know that removing persistent services from the system and Google Play services is something many people at Google feel very strongly about.
 
+Ian Lake I have noticed in some cases, the activity manager kills process (instead of the low memory killer). It is probably related to a limited number of background process or something like that(16), irrespective of available memory.
 
+Jules Archinova I agree with you regarding companies like Google (and Facebook too on most OEMs) getting special priviledges like being killed last becoming a problem. On the other hand, a file syncing process must be able to immediately resume as soon as his process is restarted. Many Android programmers come from other backgrounds and fail to understand the rather unique way in which Android handles processes (kill and restore, instead of swapping).
 
+David Gerber you are right it is able to resume in my case, once there is free memory, after manually killing some abusive "system" services if it has time to resume before they restart. Means rarely.
 
What is actually happening when swiping an app away pressing recent button? What is released? Life cycle method called? 
 
Do I understand it correctly that the only way to start foreground service is along with a sticky notification?

There's an app called Keyline Pushing, which draws 8dp grid over activities to help align the views underneath — it seems like a good candidate for a foreground service, but its notification is dismissible.
 
+Karl Heimann +David Gerber - it kills the process associated with the task stack you just swiped away. For a single process app, that means your whole app dies. For a multiple process app (say, Google Play Music which does its background playback as a separate process from the UI), this does not kill those other processes.

Any service being killed as part of that process also gets a callback to onTaskRemoved() [1] if you want to do something special in those cases - a simple example would be to call stopSelf() to prevent the automatic restart caused by START_STICKY/START_REDELIVER_INTENT (as those still apply) if you want to take the swipe away as a hard sign that you should stop everything.

[1] - http://developer.android.com/reference/android/app/Service.html#onTaskRemoved(android.content.Intent)
 
+Paul Danyliuk - yep, notifications used with startForeground() are ongoing, so they cannot be swiped away. That doesn't preclude adding a 'Stop' action though.
 
+Ian Lake but can you create a foreground service without a sticky notification?
 
+Ian Lake OK, sorry, thanks.
Well, but what about things that draw themselves over all activities, e.g. the infamous facebook chatheads (or something — not using the facebook app)? They are not accompanied by notifications, as far as I know, and frankly their presence is enough to be sure that the user is completely aware. Or maybe I don't need a foreground service for something like that?
P.S. Re-read the passage, seems like it's totally OK to be a background service.
 
+Paul Danyliuk - at one point chat heads did have a notification associated with it (it was min priority, FWIW). I know there was talk of it being unnecessary when I was at Facebook a year and a half ago.

Persistent system overlays are perhaps the worst thing possible for low specced devices though - just their existence disables some of the rendering optimizations that are even more important on slow devices, not counting running a relatively heavy service continuously.
 
+Ian Lake  -

Can you explain this words :

The only memory management that impacts activity lifecycle is the global memory across all processes, as Android decides that it is running low on memory and so need to kill background processes to get some back. If your application is sitting in the foreground starting more and more activities, it is never going into the background, so it will always hit its local process memory limit before the system ever comes close to killing its process. (And when it does kill its process, it will kill the process hosting all the activities, including whatever is currently in the foreground.)

This is from commonsBlog :

https://commonsware.com/blog/2011/10/03/activities-not-destroyed-to-free-heap-space.html 
 
+Goran Šipić - I think that's what my blog post was designed to explain in detail. Was there a specific question you had?
 
+Ian Lake - I'm getting confused about this scenario :

If an activity is paused or stopped, the system can drop it from memory… by asking it to finish (calling its finish() method).

and:

(onDestroy() is called) because the system is temporarily destroying this instance of the activity to save space

you might think that Android will destroy activities to free up heap space. I envisioned Android checking free heap space from time to time, and when it fell below some threshold, it would destroy an activity that had been pushed into the background, thereby freeing up its heap space.

Apparently, that is not the case. And, to the extent that I steered you wrong on this point previously, please accept my sincere apologies.
 
+Ian Lake  So if a have running application : 
and have activities : A , B , C and C is on top of stack then A,B is never going to be killed
only if my application is on foreground (or activity C)

only when a press home button only then activities on my application is going to be killed.  

am i right ?
 
+Goran Šipić - close: as mentioned in my blog post, only entire processes are killed - never single activities. When you hit the home button, that moves your (previously foreground) process to a background process, making it more likely to be killed in the future. However as mentioned, it may actually live on as a background process for quite some time, depending on overall memory pressure.
 
+Ian Lake  Thanks for help Ian, only one question to ask you  :) 

So if a have A, B, C activities and C is on top of stack, and my app is on foreground:

is that means that C in on foreground process and A,B are on background process. 

and when a press Home button than all activities A,B,C are on background process.

if you answer me to this question then a will understand all ...

Thanks again for you help !
 
+Goran Šipić - unless you specifically add a android:process tag to your activities, they'll all be in the same process
 
Hello, +Ian Lake . I'd like to clear this bit "That means kicking off that super important long running operation in a separate thread from within your Activity might meet with disaster when you suddenly become a background process." Does this really mean that whenever I spin off some work on background Thread, the whole process becomes a background process along with an Activity in it? Or does this mean that this can happen only if thread will outlive an Activity?
 
+Dmitry Suzdalev - I'm talking specifically about the case where the thread outlives the activity. Android only cares about component level changes (I.e., your Activity going into the background) when changing process priorities
 
+Ian Lake Hi can Activity be destroyed during EXECUTING Lifecycle methods.

My opinion is that System can kill the activity after the lifecycle callback method completes NOT DURING EXECUTING. And that is true for every lifecycle method in Activity. 
 
+Goran Šipić - assuming something isn't crashing (which could obviously take down the entire process) and you aren't doing long running work in the lifecycle methods (they are on the main thread so you shouldn't be..), yes, the entire method should complete.
 
+Ian Lake I understand so in First case if a have Unhandled exception, method will End before return, and in other case if a have long running operation on Main Thread (LIFECYCLE METHOD) android will KILL app with message "Application Not Responding" (ANR) dialog and of course lifecycle method in that case will also END before RETURN.
Add a comment...