Short explanation of Android Memory usage for new people
This is by far NOT to be considered ALL of how Android manages memory, just a baseline explanation. You can read further either through xda-developers, or a Google search for Let me google that for you.
If you're coming from a Windows machine, you already know the rule of thumb -- the more processes in the background, the slower the machine -- this is where Linux/Unix differs, and since Android is built on the Linux kernel, it's only appropriate that it manages memory the same way.
When you start Linux, a ton of daemons (of course "ton" could be more or less depending on how many packages you have installed) start and stay in the background. When not in use, these daemons are "sleeping." A sleeping daemon does not actively use memory, but rather occupies a small amount just so it can be woken more quickly. In Windows, all processes in the background are considered active and on the loose.
In Android, it has a built-in mechanism for managing these sleeping processes so that whenever the internal memory reaches a certain low point, the least used process is GRACEFULLY shut down (in it's proper sequence, NOT kicked loose like in task killers). This is why task killers (though in some uses, are useful, if you know what you're doing or if you have something lock up) are not great for Android. These hard-coded killoff points are already in there, but their set from the manufacturer pretty low, so doing a multitude of things and multitasking even though it won't freeze the device, will make it slow because there's clutter in there not being used.
Autokiller (root required and free from the market) allows you to adjust these killoff points using presets. You don't need to have an in-depth working knowledge of what you should set for each parameter, just choose a preset. Android will still boot with it's factory defaults, but Autokiller will start automatically and re-adjust them to the preset you chose.
11-17-2010 10:59 AM
If people are wondering why their machine is running slowly. This describes one cause. Just like PCs the more free RAM, the happier your tablet is. The killoff points and how many apps you have loaded can impact performance and stability.
gurgle Tech stooge of the Internet
Tablets Currently in Possession -Partial List
--Fujitsu Stylistic LT TabletPC-Win98 / HP4400-W7U / Samsung Q1U- XPPro/V-Ult/Archos 9
-- WItS A81E/ Archos 5/500 Archos 7HT/Archos 101/16/Asus Transformer 10.1/32 / G1
Remember-If You do not open it, you do not Own it
I should also add if you try Autokiller, don't ante up and pick the highest preset, could cause BIG problems...start low on "Moderate" and see how it acts...if you're an overclocking, non-multitasking guru then maybe you want "Optimum"...for reference, I have a Haipad M701-R using Launcher Pro, uninstalled the factory task manager with Titanium backup, and have Autokiller set to "Optimum" and my tablet runs smooth as glass. Haven't tried any of the higher settings though...and the more widgets (I'm not using any), the more memory you want as a cushion...if you have widgets on all homescreens, then maybe you should go with "Moderate."
Not enough people listen to this.
The one thing that bugs me with AutoKiller is that the dev is implementing some memory display features that eat up RAM. If you are on a ROM that supports bootup scripts, it's better to just echo the line directly into /sys somewhere... Marginally anyway. Once your devices has around 180MB RAM total it's not as big of a deal.
One place where you want to ignore this advice is with the Archos 7 Home Tablet and anything based on Rockchip RK2808 not running the lowmemkiller driver some modders compiled. The built in memory management driver was never built for some reason for that platform. Failure to manually kill apps results in the system slowing down to a complete halt forcing a hard reboot.
Sounds like something that should be fairly simple for a dev to implement...I wonder why it hasn't come to fruition? If I knew anything about writing code or programming period I'd rip lowmemkiller out of another ROM and start tweaking to make it right (per chipset) for these devices
Originally Posted by xaueious
There is an app in the Android Market called "Auto Memory Manager". I use it on my Motorola Backflip, which has Android 2.1 with 256MB. Auto Memory Manager will help. You can set thresholds in it, if the phone or tablet goes past the threshold, it will start by shutting down non essential apps. If configured right, the app work wonders.
There is another way to get around the low memory problem also. If you have rooted your Android phone or tablet, you can Google about creating a swap partition on your SD card. Swap partitions in Linux work like virtual memory in Windows. It is the same concept. The OS needs extra memory, it allocated an area of the hard disk (PC, but in the case SD Card) for RAM.
More memory in most cases equals more speed and response.
Last edited by AirborneDude; 12-10-2010 at 09:24 AM.
+1 on the swap partitions...but people should be informed that using a partition editor can most DEFINITELY brick your device with the greatest of ease if not done 100% properly (I know you were referring to SD but in case someone stumbles on a partition editor thinking that's the right one). There is a custom recovery out on the interwebs called firerat's custom MTD mod which lets you re-partition your phone. But, this doesn't give you more RAM, just virtual memory as you mentioned...won't be as "fast" *technically* because RAM is considered faster than filesystem memory, but these devices use flash memory so I can't see where there would be any speed degradation.
I haven't looked into the SD swap thing though...very interesting...I'll have to take a look around at that. What happens though, if your SD kicks bricks or you accidentally format it, or you just decide you want to go bigger? I know about Darktremor which enables an EXT partition on the SD card and lets you install apps2sd via script...makes since that this method would work, my only hangup is what-if (I realize it's a BIG what-if) an SD card failure occurs and the boot partition can't find the swap partition, or something gets corrupted?
I have read about people adding the Linux swap partition to their SD cards and doing a few commands (On command line) on their rooted phones and running Android just fine. If you have a phone or tablet with only 256mb, this could be something to try. I have also saw a swap app in the Android Market that supposedly works without going to the command line, but again, you have to have a rooted phone.
I think someone ought to suggest to Google that a swap partition option on the SD should be an option in Android. Maybe this option would only be offered when you insert are band new SD card. Or maybe Google could take GParted (Open source Linux partition app) and make a light version to only create swap partition and move data if the SD card has data.
And to answer your question of SD failure. I don't think it would matter, Android would use the memory on the device. Of course your phone might be lagging bad and you might need to delete some of your widgets that you used after you you created your swap.
Last edited by AirborneDude; 01-09-2011 at 09:41 PM.
Anroid apps are really a revolutionary thing in the IT field and I , being a non it person would like thank you for your description. it has helped me a lot in gaining proper understanding about anroid....
Sorry, commercial links are not allowed in signatures, signatures or visitor messages. Thank you.
-1 on swap usage, in terms of the full picture, id much prefer to keep things in RAM as opposed to sd.
A) it will keep the sd card active and chewing up more power
B) it will increase the writes on the sd card, as they have a lot more limited write cycles than magnetic storage = less time before failure as although RAM is also non magnetic, can handle a lot more writes.
C) sd card is going to be incredibly slow compared to RAM.
I would say due to the fact we have the awesomeness of the linux page managment and things like 'decent thread managment', we should more actively focus on optimisation of the dalvik mem management, and the vmem kernel side management, secondary to this a slight bummer to using java for apps is the memory footprint is what I like to call 'bloated like crap' but to make android useful we needed it... (think of how much less android would have been used if it weren't for the market), id like to see the devices more heavy optimised, ram increased by manafacturers, and techs that can help with bloat used more fully (jazelle is a prime candidate).
To be honest any of those 3 things should make the tablet world smooth and quick for the most part.
Sent from my S7