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
Related
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
Let's say I'm using an app which is both RAM and CPU intensive and I get a call which I'm bound to be on for say, a minute. In this case, I want to know what will be the fate of the application. Will it still continue its execution in the background and will its priority be changed?
Also, if at all the app uses higher amounts of RAM and CPU, is there any chance that the app will be shutdown by the android OS?
Please share any resources and documentation that discusses this subject. Thanks in advance. :)
Will it still continue its execution in the background
For at least a few milliseconds, yes. Regardless of how an application moves to the background, once in the background, its process is eligible to be terminated, to free up RAM for other apps. When that occurs depends upon a lot of variables -- it could be milliseconds, it could be hours.
and will its priority be changed?
Background applications' processes run in a class that helps limit their CPU utilization.
Also, if at all the app uses higher amounts of RAM and CPU, is there any chance that the app will be shutdown by the android OS?
Regardless of amounts of RAM and CPU, the app's process may be terminated by Android at any point when it is in the background.
It's important to distinguish between the app itself and the Activity that is being obscured. An Activity is just part of an application. When an Activity is hidden certain lifecycle methods are called depdning on whether it is partially hidden (onPause) or fully hidden (onStop). This does not necessarily affect the background processes that you started before the Activity was obscured. Even when an Activity is hidden, the app still exists. Background threads and services you started while a given Activity was the foreground will still be running (assuming the OS is not low on resources) as part of the existing app process.
What you should do is think about how to handle the result of these background processes within the other lifecycle methods (e.g. onResume) should they complete durring or after the obscured state ends.
I've been reading that Android (like most of mobile OS's) doesn't "exit" applications.
When we press the back button, the application is still in the background (like an iddle state).
So, I'd like to know, what doees it do when there's too many apps running in the background?
From official Android developer guide:
The Android system tries to maintain
an application process for as long as
possible, but eventually it will need
to remove old processes when memory
runs low. To determine which processes
to keep and which to kill, Android
places each process into an
"importance hierarchy" based on the
components running in it and the state
of those components. Processes with
the lowest importance are eliminated
first, then those with the next
lowest, and so on.
From a user's perspective, the more memory an Android device has, the better. Why? Applications that aren't used are "idle" and take up a part of device's RAM.
Every time you start an application from zero, that is, an application that isn't idle, Android's CPU will use up resources to bring it to life and into memory.
When an app goes into idle mode and, later, back into active mode, it won't use up that much CPU. And CPU usage is the main battery drainer, if we don't take GPS, WI-FI and Bluetooth into account.
So, what does this all mean? You want applications that you use often to reside in memory, so that CPU isn't used as much. Android will keep them alive, based on priority.
This is the reason why task killers are a bad idea, and this is why they won't work anymore in Android 2.2, Froyo.
Oh the usual, android just goes on a killing spree
Line 8544: 01-24 18:41:30.610 I/am_kill ( 2474): [5601,com.google.android.youtube,12,too many background]
Line 8655: 01-24 18:42:15.637 I/am_kill ( 2474): [5995,com.sec.android.app.camera:CropImage,12,too many background]
Line 8714: 01-24 18:42:26.505 I/am_kill ( 2474): [5961,com.sec.android.app.camera,12,too many background]
The activity gets killed. This should not be a problem, because the developer read this manual, and coded for it :)
http://developer.android.com/guide/topics/fundamentals.html#lcycles
Define 'too many'. :-)
Idle apps don't use resources (unless specifically programmed to do so).
If the phone goes low on memory, the apps with the lowest priority are killed and memory reclaimed.
Task killers on Android are inherently unnecessary.
Read more about this here: Why You Shouldn’t Be Using a Task Killer with Android
When the operating system needs more capacity for new activities to run, it shuts down background tasks. So for example if you start the Browser application, which has large resource requirements, many background activities will be shut down.
You can write Android applications to run as a Service though, and they will not be shut down, and will continue to run in the background.
Read these topics for more details:
http://developer.android.com/guide/topics/fundamentals.html
http://developer.android.com/reference/android/app/Activity.html
Android manages the task of asking Activities to finish when it wants to reallocate resources.
From the "Application Fundamentals" page on the developer guide:
If an activity is paused or stopped,
the system can drop it from memory
either by asking it to finish (calling
its finish() method), or simply
killing its process. When it is
displayed again to the user, it must
be completely restarted and restored
to its previous state
http://developer.android.com/guide/topics/fundamentals.html#lcycles
Basically, Android lets processes run in the background until it needs the resources, at which point it kills some of these processed to reclaim the memory.
Here is a link to a good explanation of the issue, it is at the root of the "Do I Need a Task Killer" issue many Android users argue over.
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
Is there something in the Android developer guidelines that disuades developers from providing the option to "exit" (stop running) an application from within the application itself?
I love multitasking and all but it's not clear to me why:
the vast majority of apps don't have their own Exit functions and hence just keep running forever
don't give you a choice about running when you turn on the phone - they just do by default
Both of these things lead to memory usage constantly increasing and your device running with this performance burden all of the time despite the fact that you may only want certain apps to run some of the time.
Am I missing something?
Is there something in the Android
developer guidelines that disuadea
developers from providing the option
to "exit" (stop running) an
application from within the
application itself?
Yes. It is generally not needed, just as it is generally not needed to restart a Web server because some user with a browser decided (s)he is done with a Web app.
the vast majority of apps don't have
their own Exit functions and hence
just keep running forever
They don't keep running forever. Android will close things up as needed.
don't give you a choice about running
when you turn on the phone - they just
do by default
Those developers aren't paying attention to me.
Both of these things lead to memory
usage constantly increasing
Generally, it doesn't. If you find specific apps that do this, uninstall them.
and your device running with this
performance burden all of the time
Generally, it doesn't. If you find specific apps that do this, uninstall them.
Also, this question is a duplicate of this one.
"Both of these things lead to memory usage constantly increasing"
Which doesn't matter since Android apps are limited to a fixed amount of RAM. Freeing RAM won't give more RAM to other apps.
Essentially, there's no need for a quit button as long as the developer does a good job of designing their app. Android activities are stopped when they aren't visible and resources are needed elsewhere, so the are no longer consuming resources. You can read about the lifecycle here:
Here's a related question:
From Google's Android Application Fundamentals page:
Shutting down components
A content provider is active only while it's responding to a request from a ContentResolver. And a broadcast receiver is active only while it's responding to a broadcast message. So there's no need to explicitly shut down these components.
Activities, on the other hand, provide the user interface. They're in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:
An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().
A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().
Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components. A later section, Component Lifecycles, discusses this possibility and its ramifications in more detail.
So it seems like Content Providers and Broadcast receivers should never be explicitly shut down, as they are inert while not handling their specific events.
As for Activities, I would argue in favor of having an end to it, but in certain cases. If your app has a finite state in which the user is done using it, why keep it alive until GC gets it? The activity manager still needs to keep track of that Activity while the user has finished their task. My best example for this is the Calculator. You open it, you have it solve a problem for you, and then you close it. If the onCreate function is so expensive that it's more effective to do onCreate once and then onRestart whenever the user moseys back to your application then you're probably doing something wrong. Maybe I'm misinterpreting how Android handles Activities, and if so I'm always interested in learning more :)
It all comes back to the answer that users want total control of their running and auto-start list and what they do and don't want installed, example: google maps, etc etc. there are no two ways about this.