I have noticed that the facebook android app is extremely resilient and cannot be shut down. Even though I have forced stop the application and killed all its associated services, it is somehow able to magically restart itself after a while.
This leads me to the questions:
1) How do I actually stop the app and all facebook services without uninstalling it.
2) What methodology does the app apply to prevent itself from getting killed (i.e. how do you program something similar in android)?
1) How do I actually stop the app and all facebook services without
uninstalling it.
Process termination is executed whenever Android needs more resources to handle logic of another processes of higher priority.
How does it apply to the Android's Service?
The Service returns specific code in onStartCommand():
START_STICKY - briefly speaking, once the application's process is killed by returning this constant we ask the OS to restore the application's Service whenever available resources appear. Thus, the application's process is recreated.
START_NOT_STICKY - once the application's process is killed by returning this constant we tell the OS to not to bother about our Service recreation.
START_REDELIVER_INTENT - same as START_STICKY but with subtle distinction. Whenever our Service is restored we demand to have the onStartCommand() with same Intent we delivered for the last time before termination.
The explanation for your observations could be that Facebook uses aforementioned constants to bring Services back to work.
2) What methodology does the app apply to prevent itself from getting
killed (i.e. how do you program something similar in android)?
Few things are worth remembering whenever we want to prevent our application from being a first candidate to be terminated:
Relying on Activity.onLowMemory() or Application.onLowMemory() methods - if we hide the application to the background or abandon it then this method is invoked. In this case it is worth releasing resources including:
Caches or Cache entries (e. g. LruCache),
Expensive objects (Bitmap, temporary POJOs, etc.)
unregistering dynamic BroadcastReceivers
Unregistering statically declared broadcast receivers whenever we don't need them.
Preventing application from having memory leaks - most of the processes leaking their memory are undisputably the first ones to be terminated by the system.
Preventing from objects creation and designing our code to be immutable (book) (link)
organizing our HTTP requests in batches (link) (link) (link) (link) instead executing them on demand.
Hope that helps somehow.
Related
I am developing a simple app that just play a white noise sound in background while I am doing other things.
It works very well when I switch to other apps ( like games, chrome browser, etc ) but sometimes ( for example when there are many chrome tab opened ) the white noise sound stop and I need to reload my app.
I am NOT using Services, is this the reason ?
Because your apps is getting killed by the system to give up resources for to other apps (games, chrome, etc). So you need to use a Service.
Here an excerpt from Processes and Application Life Cycle
for more details explanation:
An unusual and fundamental feature of Android is that an application
process's lifetime is not directly controlled by the application
itself. Instead, it is determined by the system through a combination
of the parts of the application that the system knows are running, how
important these things are to the user, and how much overall memory is
available in the system.
...
A cached process is one that is not currently needed, so the system is free to kill it as desired when memory is needed elsewhere. In a
normally behaving system, these are the only processes involved in
memory management: a well running system will have multiple cached
processes always available (for more efficient switching between
applications) and regularly kill the oldest ones as needed. Only in
very critical (and undesirable) situations will the system get to a
point where all cached processes are killed and it must start killing
service processes. These processes often hold one or more Activity
instances that are not currently visible to the user (the onStop()
method has been called and returned). Provided they implement their
Activity life-cycle correctly (see Activity for more details), when
the system kills such processes it will not impact the user's
experience when returning to that app: it can restore the previously
saved state when the associated activity is recreated in a new
process.
I think Services is What You are looking For.
A Service is an application component that can perform long-running
operations in the background, and it does not provide a user
interface.
For better chance of preventing OS to kill your app, you should use a
Foreground Service
following the official guide here: https://developer.android.com/guide/components/services.html#Foreground
Remember that there is no way to be certain that OS will never kill your app, because when RAM becomes really low it could kill every process indipendently from type, following his priority rules
I have a Service running in the same process as my Application.
Sometimes the Android OS decides to kill my service (probably due to low memory).
My question is: does my Application get killed along with the Service? or how does it work exactly?
Thanks!
First be sure to read: http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle
The key to this is that on Android a process is just a container for code -- or specifically one or more components (activities, services, receivers, providers). By default all components in a .apk get their own, dedicated process, that they all run in together. This is almost always what you want.
When the user is directly interacting with a component of that process (that is an activity) Android will try very hard to keep that process running, and you won't see it killed except under extraordinary circumstances.
When the user is no longer directly interacting with the process, then it becomes expendable relative to other processes as described in the referenced documentation. That is, empty processes (no interesting components) will be killed before processes holding activities that the user had been using, which will be killed before processes with running services. So having a running service will tend to keep your process around at the expense of other processes.
At the same time, we need to deal well with more and more applications leaving services running, often indefinitely, and often with memory leaks. So has a service runs for an increasingly long time, Android will try less and less hard to keep its process going. Effectively this means moving it down to the background bucket until the out of memory killer takes it out. After that, if the service still wants to run, then a new process will be created for it to be restarted in.
The upshot is that for normal services that are running a long time, it is expected behavior that their process will get killed after a while. This doesn't need to stop the service; a service that wants to continue running will do so, it will just need to be instantiated in a new process.
Of course as long as the user is interacting with an activity in your process, the process won't be killed, since this pulls it to the foreground category regardless of what is going on with any services in it.
Processes are killed by the low memory killer, not Applications. So unless you do extra work to get your Service running in a different process, then your Activities are killed along with your Service.
The low memory killer doesn't try to destroy any objects in your process, although the activity manager may call onDestroy on Activity objects that are no longer needed. But that happens as part of the regular activity lifecycle, not due to low memory conditions.
(By the way, I'm unclear whether you mean "application" in general, or your object that extends Application, or whether you mean your Activities that show the UI.)
An application is something that has a user interface and if you have included a service along with it, then definitely it will be killed since Applications are terminated once the cached application queue becomes full
so create Service separate from application or in other words create an other project for it :)
btw, i'm not an experienced Android developer but thats i think what i learned by watching the Android development life cycle videos by Google
I'm trying to find the official documentation about the Android Application class lifecycle. Apparently, for what I found on StackOverflow here and here the Application class can be killed if the system needs memory. Even this tutorial says so.
But few things irritates me a bit about this:
I can't find an official documentation telling me that yes, the Application class can be killed on low memory.
I can't find any official diagram representing the Application lifecycle neither.
I can't find any proper callback to use when the Application class is killed except onLowMemory(). Does it mean that I have to use this method to persist my data?
If the Application class is killed on low memory pressure and the app comes to foreground again, how can I know in its onCreate() that the app has been recreated after a system kill? In an Activity I would test the savedInstanceState, but as far as I know there is nothing similar in the Application class.
Thank you for your enlightenments.
I can't find an official documentation telling me that yes, the Application class can be killed on low memory.
Below are the references to where it's been stated:
Application Fundamentals
Processes and Threads
Multitasking the Android Way
I can't find any official diagram representing the Application lifecycle neither.
This is a reasonable observation... Although the following is opinion-based, my best guess is that such a diagram would contradict the Android's multitasking "philosophy" as described in the last reference provided:
"A key to how Android handles applications in this way is that processes don't shut down cleanly. When the user leaves an application, its process is kept around in the background, allowing it to continue working (for example downloading web pages) if needed, and come immediately to the foreground if the user returns to it. If a device never runs out of memory, then Android will keep all of these processes around, truly leaving all applications "running" all of the time."
I can't find any proper callback to use when the Application class is killed excepted onLowMemory(). Does it mean that I have to use this method to persist my data?
Regarding onLowMemory() whose description is quite straightforward, are we talking about a background process or foreground UI?...
If none of application Activities is in foreground and OS is low on memory, it may kill the app so that none of the Application's or the app component's (Activity, Service) callbacks will be invoked. That said, (since you're dealing with Activities) I recommend to store all persistent data as per the documentation, in onPause().
If the Application class is killed on low memory pressure and the app comes to foreground again, how can I know in its onCreate() that the app has been recreated after a system kill?
You can't recognize it in Application's onCreate().
As far as I know, you can't handle the application killed event. Here is a quote from the Application's onTerminate method:
This method is for use in emulated process environments. It will never
be called on a production Android device, where processes are removed
by simply killing them; no user code (including this callback) is
executed when doing so.
The general idea is that you shouldn't care whether the application was killed or not. If it was, the OS will restart the app next time it is needed otherwise it will be resume (and you'll use the Activity / Fragment lifecycle events to achieve this).
What data do you need to store - is it possible to store it earlier (when it is received from web service and so on) instead of waiting for the last moment?
What is empty process in android and what is it’s use.
I have seen empty process in my device sometime and it shows process with 0 services ,0 activities means process with no components inside it .
I also want to know if as a developer,it's of any use or it's just useful on OS level.
What is empty process in android
It is a process with no running activities, services, or broadcast receivers (and where nothing presently is connected to one of the app's content providers, if any, though this is a fairly obscure case).
what is it’s use
Once upon a time, the process did have activities, services, and/or broadcast receivers. However, those components were destroyed as a part of their normal operation (e.g., a manifest-registered receiver returned from onReceive()). Right now, the process is being held onto, just in case that a process for the same app is needed again. Eventually, though, the empty process will be terminated, to free up system RAM for other processes.
I also want to know if as a developer,it's of any use or it's just useful on OS level.
Mostly, it is an OS-level optimization to improve device performance and responsiveness, compared with terminating the process immediately when the last running component was destroyed.
What is Empty process?
Process that doesn't hold any active application components.
What is it use?
The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it.
The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.
I have a Service running in the same process as my Application.
Sometimes the Android OS decides to kill my service (probably due to low memory).
My question is: does my Application get killed along with the Service? or how does it work exactly?
Thanks!
First be sure to read: http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle
The key to this is that on Android a process is just a container for code -- or specifically one or more components (activities, services, receivers, providers). By default all components in a .apk get their own, dedicated process, that they all run in together. This is almost always what you want.
When the user is directly interacting with a component of that process (that is an activity) Android will try very hard to keep that process running, and you won't see it killed except under extraordinary circumstances.
When the user is no longer directly interacting with the process, then it becomes expendable relative to other processes as described in the referenced documentation. That is, empty processes (no interesting components) will be killed before processes holding activities that the user had been using, which will be killed before processes with running services. So having a running service will tend to keep your process around at the expense of other processes.
At the same time, we need to deal well with more and more applications leaving services running, often indefinitely, and often with memory leaks. So has a service runs for an increasingly long time, Android will try less and less hard to keep its process going. Effectively this means moving it down to the background bucket until the out of memory killer takes it out. After that, if the service still wants to run, then a new process will be created for it to be restarted in.
The upshot is that for normal services that are running a long time, it is expected behavior that their process will get killed after a while. This doesn't need to stop the service; a service that wants to continue running will do so, it will just need to be instantiated in a new process.
Of course as long as the user is interacting with an activity in your process, the process won't be killed, since this pulls it to the foreground category regardless of what is going on with any services in it.
Processes are killed by the low memory killer, not Applications. So unless you do extra work to get your Service running in a different process, then your Activities are killed along with your Service.
The low memory killer doesn't try to destroy any objects in your process, although the activity manager may call onDestroy on Activity objects that are no longer needed. But that happens as part of the regular activity lifecycle, not due to low memory conditions.
(By the way, I'm unclear whether you mean "application" in general, or your object that extends Application, or whether you mean your Activities that show the UI.)
An application is something that has a user interface and if you have included a service along with it, then definitely it will be killed since Applications are terminated once the cached application queue becomes full
so create Service separate from application or in other words create an other project for it :)
btw, i'm not an experienced Android developer but thats i think what i learned by watching the Android development life cycle videos by Google