I am working on a project of 3rd-party Android Launcher.
I find it being killed often by OS when running in background, even it is the default Launcher.
OS will kill many apps when available memory is not enough, I guest that the reason why my Launcher is killed.
So my question is what should I do to decrease the chance of being killed ?
Nothing. You should find a way to handle the event where the OS kills your process, using a hacky approach to keep it in memory is bad, bad design and could lead to all sorts of issues on different devices.
You really shouldn't even care that the system is killing your process, the launcher should handle an intent and either resume if present or start if killed.
Related
I'm developing some Android devices that are constantly performing fairly intensive tasks.
I've noticed a strange issue happen (quite rarely, generally after 2-3 weeks of running continuously) where a device ceases to function, and all communications with it die. Since I don't have any access to these devices I can only assume that the OS has killed all running processes (there are several processes on it that communicate with several different backend servers, and they all disconnect simoultaneously)
I'm currently getting around this by implementing a firmware watchdog (by compiling it from source), but I am trying to figure out what is causing the devices to die in the first place.
Is there some android functionality that kills all processes and requires a reboot to fix? What can i do to avoid this happening? Are there any logs that I can view which show when this occurs?
Don't know what have done to the AOSP, but there do have some mechanisms to make a system reboot.
In init.rc, if a service is note as "critical" then if the service crashes more than 4 times, the system will reboot to the recovery mode.
In framework, if the a service belongs to core service and crashed, the system will restart the whole android, but not the kernel.
Temperature, there are two types temperature reboot schedule. One is CPU heat, but this has nothing to do with android, it is a CPU feature. Another, battery temperature, if a battery's heart is higher than expected, the healthd(a android demon on watching battery state) will notice the framework and the framework will reboot.
If the communication logic is written in a Android App, I suggest you to make this app as persist. This will make sure the app will stay in memory forever, and if the app is crashed, the system will restart this app. This may not solve you problem, but can resume the communication job.
I think it is not hard to figure out what's going on, usually the logcat contains the detail.
One of the explanations of your scenario is that the CPU overheats. In this case, not only the device will spontaneously shut down, it also cannot immediately reboot.
You may find temperature warnings in system log, but you can monitor this in your software, and throttle down CPU-intensive tasks to keep it from overheating.
I wrote an android app (TestApp pid:5231) and there is an independent service named "testservice"(pid:5232) in it. Now, I got an odd thing... while I run my app for long time, greater than 30 minutes on my phone, the "testservice" will be killed by system. In the log, I saw below key: "No longer want com.xxx.xxx".
Googled that key, and someone said this scenario is caused by low memory, which is the AM mechanism. From my log files, I haven't seen any low memory notice...TT "No longer want..."
is a normal scenario or a memory leak issue, Anyone know why?
From what i know, a service can be killed anytime by the Android OS depending on its policies. Even i have had my long running processes killed without any warning. Low memory issues are hardly the reason as modern smartphones seem to have a lot of memory. The only trick that has worked for me is a Foreground Service. According to Android Documentation, foreground services have higher priority to background services. Hence you might want to shift to Foreground service to solve your problem.
When an app gets put in the background and the app takes up too much memory. Is it possible for the operating system to corrupt the memory so that when the app is launched again unexpected behavior might ensue? Or will it completely kill the app when it needs the memory so that when I relaunch I'm in a clean state?
The short answer is no.
For more detail on how Android manages memory and how it affects applications, services, etc, see http://mobworld.wordpress.com/2010/07/05/memory-management-in-android/ and http://android-developers.blogspot.com/2010/04/multitasking-android-way.html
I couldn't find any good application for streaming MP3s from a URL that can run in the background that meets my requirements so I decided to write one myself. It turns out its incredibly easy to stream an MP3 with the native MediaPlayer if you're running Froyo or better, and I am.
But my problem is if I switch applications and try to keep the stream going (some of them last 2-4 hours) and play a game or something while i'm listening to it, it sometimes just dies. I'm not sure exactly what the problem is, my guess is that the Android system decided it was OK to kill that process... but it wasn't.
So is there something I can do to make it kill other processes if resources are needed instead of my streaming mp3 app?
What I have tried:
android.os.Process.setThreadPriority(android.os.Process.THREAD_PRIORITY_AUDIO);
But it's no good.
You need to make the service a foreground service, if you haven't already. Foreground services have to display an icon in the notification bar, and the Android system will not kill them unless under extreme memory pressure.
Check out the documents for startForeground()
I found that after my Droid Incredible was updated to Gingerbread (2.3.4) all of a sudden it works. I made no changes at all, it just doesn't die in Gingerbread like it did in Froyo. I know there were media player improvements in Gingerbread so I'm going to have to assume there was a bug in Froyo that was fixed in Gingerbread.
As far as i know, a program can't be running forever, at some point the OS will kill it. But what you can try is to have a service and make it generate notifications once in a while with useful information. Then, start the activity again.
This is due to an activity Lifecycle. The OS might kill your app if it need memory. You might have to consider a service
I have had problems with memory management in my Android phone, which terminated processes like you described. You may consider installing a program like Android Booster to monitor available memory and close programs that are using too much memory, so that the programs you would like to keep open have enough memory to run.
I've seen that if you kill some process, it restarts immediately and keep running. How this implemented? How to inform system that my service should not be killed and if that happened - restart it.
Android just does it. As an OS, Android is specifically designed to run with ram full at all times. So if you kill, or an app force closes it will, if their is room in ram for it be restarted by Android to fill the ram back up.
It does this because even the "fastest" phones are snails to even the most average of desktops and keeping as many programs that you use loaded in ram as possible enables it to simply "resume" the program instead of having to go through the slooooow, time wasting process of having to reload it back into ram and then running it from the beginning.
Android kernels have their own task manager. This means that it will be more efficient than any app-based task manager as it is run at the kernel level, and it should be left up to that task killer to decide when to free up memory or not free up memory. Let Android do what it was designed to do. Anything you do to try and force it to rerun a program or stop a program will, in the long run, slow it down more and possibly even cause stability issues.
However the short answer to your question is that there is no way to tell the "system" that your process should not be killed or to restart when it is closed. That is a choice made entirely by the kernel level task manager.
BTW, why would you want to? I ask this because I don't think you have thought this through very well. Remember, unlike IOS owners who are used to and expect total control over their device to be in the hands of Apple(for good or ill) Android owners expect, and will have control over their device. If you try to take that away from them, you will likely find most people uninstalling your service. And demanding their money back if you charge a fee for it.
I hope this has helped.
Not sure this is something that's good, but I've seen malware processes that have "buddy" processes that revive each other when one or more go down.
I hope whatever you're doing is ethical :-)