My Android "smart TV box" has a disk attached where I have a small Debian distribution installed running various server processes (ntp, mpd, lighttpd, ...). Problem is, even though I have plenty of swap space, some of my daemons tend to "die" when there's a lot of activity (i.e. when the machine swaps a bit more). I do not know for a fact what is the root cause, but it sounds like it might be some kind of Android OOM system deciding that it's better to kill those processes (presumably because it is tuned on the assumption that there is no swap).
How can I verify that this is indeed the case?
If it is the case, hwo can I stop the kernel from killing processes even when there's still plenty of space in the swap?
You can tweak out of memory killer writing to /sys/module/lowmemorykiller/parameters. Being a kernel killer I don't think it discriminates between android or native processes, but I may be wrong.
More detailed information can be found here
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.
If the memory or CPU usage of an android device is unusually high,will android take any kind of actions in that case? Like killing apps, reboot etc? Is there an in-built service in android that continuously monitors the CPU and memory usage and take necessary actions in case of any abnormal behavior? If available, at what threshold values of memory and cpu usage will it take action? I did perform a thorough google search but couldn't find any answers. I am talking about inbuilt feature of android and not any third party apps.
I quote this from a good article on android processes
Android does a good job of automatically managing these processes, which is why you don’t need a task killer on Android.
When Android needs more system resources, it will start killing the least important processes first. Android will start to kill empty and background processes to free up memory if you’re running low. If you need more memory — for example, if you’re playing a particularly demanding game on a device without much RAM, Android will then start to kill service processes, so your streaming music and file downloads may stop.
In most cases, Android does this all without you needing to worry about it. Android intelligently uses your device’s RAM for caching apps and other data, because there’s no point in leaving your RAM empty.
You should also read the official documentation on memory management by android operating system.
I think this should clear your doubts. Feel free to ask if you have more...
I am getting a message like "your application restarted 9 times in 5 minutes()", when I tried to clean Junk Files using "Clean Master" application.
Please find the screenshot for this issue. I am not able to figure out why this message is coming. Any idea on this???
These apps may have once been useful but the Android has progressed far enough that they are now outdated, unnecessary and rather harmful.
On Windows, you want to keep as much RAM as possible as you can so that programs have enough room to operate. When RAM fills up, Windows is forced to start using hard drive space as virtual RAM and hard drives are much slower than physical RAM.
This is not true for Android.
Android’s operating system has its own native handler for assigning RAM to apps and making sure that all of it is being used in the most optimal way. In fact, Android purposely tries to keep apps loaded into RAM for better performance. RAM is fast, remember? On mobile devices, every bit of speed is critical for a good user experience, so keeping apps in RAM is actually a good thing.
Not only does Android handle RAM assignment, but it also keeps track of background apps so they don’t use up unnecessary processor resources. There’s no noticeable performance hit for leaving apps loaded in RAM.
App killers, memory boosters, performance enhancers, etc all claim wiping memory will speed up the phone. With current versions of Android, that's simply not true. It's actually the opposite. What will happen is the task killer app kills other apps which use resources to process. Then the OS restarts those, or other apps to fill the memory again, which takes even more resources. The task killer app kills again and the process repeats over and over. So in reality, those kinds of apps reduce performance and increase battery usage by restarting apps again and again. Remember, those dormant apps don't consume any additional battery or CPU in the first place.
All,
I would like to free up ram on my android for a data intensive operation and also be able to free up ram when the user wants to. The first thing I thought of doing was running system.gc(). However, that is not a guarantee that the garbage collector will work. Any suggestions on how to immediately and guarantee that ram is freed up when the code is called.? Also, how do the apps that free up ram when you click a widget accomplish this task?
I guess a better way to phrase this is: How do I manually free up memory like the Android OS?
Thx
You don't have to do this. Android will kill lower priorized apps to free memory if you need more than currently available.
My understanding is that the theory on Android is that running applications should relinquish memory through a callback mechanism when another process with higher priority (i.e., the current foreground process) needs more memory; additionally, the OS will start killing other applications if memory demands increase further.
Therefore, if you want your application to be able to use substantially all of the system's memory, you just need to make sure it stays in the foreground or use some other mechanism to ensure that its memory demands are higher priority than other memory demands (unfortunately, I couldn't say what that latter part would look like exactly).
There's not really much you can or should do manually to free up memory outside of your specific application. The OS is doing the right thing: as memory is needed, it tells applications "delete all non-essential data" and then after that if more memory is needed it tells them to get lost. Any manual approach to freeing up memory would basically do the same thing.
Edit: It sounds like you are wondering what other "memory-freeing" applications are doing. The answer is, they're taking the manual approach and doing the same thing the OS does -- sending signals to running processes. The reason this is unnecessary is that free ram doesn't actually do you any good before you need it. The OS will do this right before you need the extra space, which ensures no processes are killed before absolutely necessary.
Android has a garbage collector. iOS does not.
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 :-)