Database Info

RAM Program Utilization?

Can someone explain to me how Program Storage space is allocated.
To the best of my understanding the Kaiser has 128MB RAM for running programs.
However, if I look in the Memory applet it shows TOTAL 95.36MB. I will assume that this is calculating in the base RAM needed to load up the ROM?
So, if I have 95.36 TOTAL it then says I have 35.19 IN USE. This is after shutting down all running programs AND removing everything from the startup menu.
I then go into task manager to look at running tasks and add up all of their memory utilization and only get between 6-7MB. Now I don't totally understand because it looks like things like file system drivers and services are listed here...I would think those things would be included in loading the device itself (and this part of that missing RAM from the 128 as mentioned above).
So with only 6-7MB accounted for in Task manager, what is taking up the remainder of the 35.19MB?
Also, does anyone have any good stats on at what % utilization the device starts to slow down? Theoretically you should be able to run very close to maximum RAM (assuming all needed apps are open).
And, another question out of curiosity is what do most people have for their base utilized RAM on a clean reboot? By this I mean you would have all your services loaded (BT, voice command, touchflo, etc.) and all your necessary today plugins, menu shells etc, but NOT applications like PIE or TCPMP. I find that mine tends to be in the 60%+ range as of right now.
Thanks for any info you can give!

Ok.. I just realized that the Task Manager had additonal tabs that I didn't see...specifically services. Now on a WindowsXP system running services will also usually list a corresponding process that shows RAM utilization. WM doesn't seem to show that information.
So it's entirely possible that all my missing RAM is taken up by additional running services. Any application that will fully detail this out for me?
Also, is there a list of services somewhere? I often go into my XP machine and disable any extraneous services... can I do the same in WM?
thx

yes, and there is also the so called "page-pool' that is a sort of cache / buffer.

th_undead said:
yes, and there is also the so called "page-pool' that is a sort of cache / buffer.
Click to expand...
Click to collapse
this is true, the higher your page pull the less ram you will have but the faster your phone will run. i remember back on my wizard i would alway set like a 32(i think it was 32 or mayb 16)mb pagepool so the phone would run super fast. but at the same time i had like 15mb of free ram....i toke a faster phone lol

Ah right the pagepool... and I think dutty's latest uses a 24MB one which could account for alot of the missing RAM.
Ok...well so here is another question.
Let's say you are running at a high memory utilization....let's say 70-80%
If you could drop that down 10-15% by decreasing your pagepool would that be more efficient? This goes back to my original question of performance as utilization levels increase.
I thought I saw a post somewhere that showed only very minor increases in performance as the pagepool was increased... is it worth that vs. the slowdown (if any) when running at a high utilization?

Out of main memory....help please

Although I have all photos, music, apps etc pointed to 'external' memory I am now getting low memory (<2MB) warnings. I have manaully purged (as much as I feel confident with) main memory and even uninstalled and re-installed programs to ensure that they reside in external memory. However when I search for files >64KB there are no files reported in main. This is driving me crazy and I need help before I microwave my HTC Diamond. Please, please point me in the right direction

The messages are probably not for storage memory but for either RAM or virtual memory. Close applications instead of minimizing them (the usual default). Get a task manager and see what's going on.

I hoped that that was the case however I have a RAM cleaner tool and even after running that and killing all processes I still have low memory. Is there any way I can determine what is taking up main memory?

you know one of my friends has the same problem with his samsung omni and i can't for the life of me find what is taking up so much room. he is pretty back to stock and we have tried everything. i tell him to return his phone as defective but he hasn't. is this a winmo problem that could be a bad code or is it just dumb luck that this has happened to an htc and samsung?

Calendar items, phone logs, messages reside in main memory too -- have you cleared those?

I do use the calendar and maybe clearing some of the old entries will help. However I do not use the handset as a voice phone, only data, and have no call logs or texts taking up space. I do use it for email so will check that too. That said it's currently using 83.36MB out of 84.56MB and doubt if the odd deletions will make a great difference. Is there a way of partitioning some of the storage card space over to extend the main storage area?

You can relocate \My Documents pretty easily with a registry change. You can also move your PIE cache (sk tools will help with this). These things might help. I thought the diamond had 4G of internal memory? Does it have a small main memory and then a large internal storage memory? I'm afraid I'm not that familiar with it.
You may want to install ClearTemp or something similar to clean out your temp and volatile folders. And you're sure it's not a ram issue? Do you have the problem immediately after a soft reset, or does it take a while?

I may have been leading you down the garden path. When I run the memory app' in Settings there are two totals: Storage and Program. In storage 82.7MB out of 84.5MB is in use and in program 78MB out of 111MB is in use. The Diamond complains of being almost out of memory shortly after it is turned on. Without a guide to follow I'm a little ill at ease attempting registry changes even though I have advanced config and PHM RegEdit installed. I will try ClearTemp if I can install it! Thanks for the help to date.

Does anyone know how to clear out the 'storage' area of the HTC as Opera is now refusing to run (not enough cache space...?) I'm facing the prospect of reloading the firmware (again) with no confidence I won't be back in this situation again in a couple of months

The out-of-memory warning message is activated after the ram memory is lower than a desired value .
The activation pattern and the threshold value are controlled by a set of registry entries under \HKCU\Software\Htc\TaskManager\
Can Play With It By Changing The Threshold Value In Registry.

Thanks for that, however at < 1-2MB of storage area remaining my problem is how do I recover storage capacity? I used ClearTemp and I now have around 7MB free which is much better though not ideal. Surely there must be a way of tweaking the storage / program balance through one of the toolkits?

I had the same prob few month back. The best way is to Hard reset > reinstall programs your REALLY NEED to internal storage except .net C Framework or Smart Protect etc... [install those types of programs to main memory]
The other way is
Buy SkTools if you dont have it
move things ie. programs to internal storage!

I select internal memory every time I install an app which further mystifies me. Now I can't get Opera to run.... it's just a year of break downs for me

Filesys.exe uses too much RAM

Filesys.exe uses 16 of my 64mb of RAM on my wm6.1 device. Does anyone know how to reduce this (im using sktools to optimize mem but it doesnt help.)
Filesys modules:
flx_wm_av_dll.dll
coredll.dll.0409.mui
btp_btfsd.dll
ole32.dll
sqlcese30.sys.dll
msasn1.dll
crypt32.dll
rsaenh.dll
relfsd.dll
diskcache.dll
fsreplxfilt.dll
fatfsd.dll
cecompr.dll
fsdspy.dll
imgfs.dll
mspart.dll
smflash.dll
fsdmgr.dll
certmod.dll
coredll.dll
Thanks,
Will

Try decreasing the file system cache. I don't know if the glyph cache or the file filter cache will help or not, but you could also decrease them to find out. Still, 16 MB seems like a lot. I just checked my filesys.exe, and it's ~2MB (I have the cache at 2 MB for the helluvit, but frequently run it at 8 MB). You can decrease the file and glyph cache with sk tools, but you'll need to edit the registry or use advanced configuration to tweak the filter system cache (fsreplxfilt).
Do you have a bunch of over-written rom files? I think that might increase the ram usage of filesys.exe (not sure, just a guess); I've read that over-written files go into ram, but am not 100% sure on this. You should use sk tools to check for over-written rom files, and see if you have like around 14 MB worth of them (maybe for an updated net framework).
Edit: here's the reg setting for fsreplxfilt:
[HKEY_LOCAL_MACHINE\System\StorageManager\Filters\fsreplxfilt]
"ReplStoreCacheSize"=dword:00001000
My value is for 4096 sectors. I'm not sure that reducing the value from what you have will help, but it's worth looking into.

After doing what you said, I was able to reduce the size to 14mb. Anything else I could try?

I'm all out of ideas at this point. How are you getting the reading of 14 MB-which task manager are you using? When I used dotFred's task manager, I see that ~2 MB are being used. But with SK Tools, I see the size is ~10 MB, and the heap size is around 5 MB. I think they have a different way of calculating the ram usage, and SK may be including virtual memory alotments into the sum. Check this article for more on VM, but I have a feeling you're ok. I don't really understand this stuff 100%, but here's a screen-cap of my VM alotments right now (each slot has 32 MB). The second slot is filesys.exe. You can see that most of the memory allocated on the bottom (where the heaps and source code is) is green-this is memory that has been committed to filesys.exe, but isn't actually being used. I suspect that SK Tools includes that in the 14 MB of usage (and maybe the dll's at the top), but a different task manager like dotFred's won't. I have no idea how you would go about lowering the commitment, or if it is possible at all. Try a different task manager and see how things look.
Edit: I switched my cache-size back to 8 MB-that may be all the green, but when I ran the virtualmemory.exe with a 2 MB cache, I seem to recall it looked about the same.
Ok, I went and estimated the size of the commitments in my filesys memory slot. On the bottom, the green (allocated but unused) is ~10 MB, and the blue (used) is ~2 MB. The total size is 12 MB (obviously), and the dll alotment at the top is ~4.7 MB. I guess that SK tools is listing the size as the 10 MB of unused but allocated VM. The 2 MB that is in use appears to be what dotFred's task manager reports. I'm not sure what's up with the heap size that sk tools reports (5 MB), but I guess it must include the blue and some of the green on the bottom. There's still ~15 MB of free virtual memory available in the slot. You run into memory errors when that number gets low (or it runs out), even if there is free ram. I don't believe that the green alotments actually use ram-this is just reserved virtual memory. I also am not sure how you spell alotment-I decided to go with on 't,' lol.
If you read the help section for the sk tools task manager (processes), it says "the utility displays the amount of memory used by the process. In Settings, you can select to display used dynamic memory as well. (Some programs display used dynamic memory as total used memory amount; this is incorrect, and may lead to confusion.)" I think this is clearly where the confusion lies. I'm not sure what they're talking about in Settings, though-all I see is the choice to display the heap size-I guess this is the used dynamic memory, as they call it. I'm not sure why it doesn't jive with what dotFred's displays. I guess it's just bean counting in the end, and there's different ways to add things up.

DotFreds TM says about 14mb - just like sktools. Is 25 mb free mem after boot acceptable for a 64mb pda? It was never much better, even with m2d uninstalled.

Yes. I have a P3400 with 64 mb RAM too and I get 22-25 free ram at startup and 18-20 free after some usage.

not clear to me from search what is current state of swap && / || CCache

Can anyone direct me to a guide somewhere?
I'd like to make an ext partition? Or would I? Is Swapper 2 just as fast? Tradoffs? Anyone run into their sd card wearing out yet?

bueler?
The message you have entered is too short. Please lengthen your message to at least 10 characters.

The consensus seem to be "do not use" except as 'last resort', and only needed on phones with 256MB or less of mem.
I wrote this, and I am waiting for a technical review from some experts in this field.
http://forum.xda-developers.com/showthread.php?t=897823

kschang said:
The consensus seem to be "do not use" except as 'last resort', and only needed on phones with 256MB or less of mem.
I wrote this, and I am waiting for a technical review from some experts in this field.
http://forum.xda-developers.com/showthread.php?t=897823
Click to expand...
Click to collapse
I have 256MB ram
At the moment, Compcache is good enough, but I can't help but wonder how much better it could be with swap instead of Compcache.
edit: "For example, If you have a 256MB system (shows as 262MB due to 1024 vs. 1000 KB size difference) and have 130MB of apps and data/cache loaded, then that leaves about 130MB for the system to actually RUN programs. That sounds like a lot, but in reality that is not enough, since the system itself takes 50-80MB, and services will take up another 30-50MB, leaving almost nothing. "
quick review, you don't appear to be differentiating between RAM and Flash? Having more apps installed shouldn't increase RAM usage at all. Unless I gravely misunderstand the Android OS, if I install a new program, it resides in the system flash, not the RAM, until I run it, at which point it gets loaded to RAM. When the system needs memory and no swap or Compcache is in use, it writes the state of the application to the flash and removes it from RAM.
What the swap does is similar to what compcache does-- compresses apps that are currently in RAM, and moves them to the swap space. In the case of Compcache, this is in the RAM. But since you're compressing it, background apps don't take nearly as much RAM, and you get an app switching speedboost because the processor can uncompress the compcache'd program, "move" it to RAM, compress the currently running program in RAM, and "move" it to the compcache. Forgive me if you already said this, I can't read the entire thing at the moment.
As for swap, I'm not sure if the processor compresses before going to the hard swap file, I don't think that it does-- when android starts getting low on RAM, it moves what was in RAM, to the swap on the SD-card. Since it does this when the system is low on RAM, and not when the system runs out of RAM, you never notice it. Reading the app back from the SD card happens almost instantaneously, because the sd cards can be read from at a speed of at least 20MB/s, maybe more. When you're restoring an app to RAM, 20MB/s is plenty.
edit2: I'm sorry but this guide is too vague to be anything more than moderately informative. Comments like:
-"CompCache, or "compressed cache", is handled by the Linux kernel. It takes a portion of your memory, and use it as a cache space, but compressed. By using on-the-fly compression it is able to make your memory appear to be a bit larger than it actually is. However, the result is slower performance.
This is usually NOT tweakble without mod ROM such as Cyanogen Mod. The kernel also must support this feature, and not all do. This also slows your phone. "
-"...swap space by either creating a swap file or a swap partition. This adds a lot of read/write action to your SD card and may substantially decrease its usable life."
-"This really slows your phone."
People wouldn't be doing these things for no reason. Compcache does not "make your memory appear a bit larger", when it at least doubles the amount of usable RAM-- when you allocate 60MB, if you average 75% compression (I usually see between 65% and 80%), do you know how much RAM this effectively nets you? Over at least 60MB extra, usually about 80! So my phone goes from having 256MB ram to having 340 effectively. Having your processor overclocked minimizes any slowdown from the compression/decompression; I haven't noticed any slowdown, and having the "extra" RAM definitely has made my phone more able to multitask.
You basically discourage users from doing ANYTHING like swapping, compcaching, etc to their phone, saying it "slows it down" and "can substantially decrease your SD Card's life". My experience has been otherwise regarding slowing it down, and regarding the SD card, the only part that would actually go bad is the swap partition. If you put that at the end of the drive, when it goes bad, you'll know, and you can just move the partition back 300MB and put your 300MB swap there. We haven't heard of any users' cards going bad from this yet. Also, if you have a class 6+ SD Card, they implement wear leveling on the card, so you don't need to worry about wearing out any individual bits.
Sorry, I'm just not digging it.

rancur3p1c said:
I have 256MB ram
Click to expand...
Click to collapse
Me too, me too...
At the moment, Compcache is good enough, but I can't help but wonder how much better it could be with swap instead of Compcache.
Click to expand...
Click to collapse
So try it. With CM612, I have CompCache AND Swap (through Swapper2 / 128 MB) turned on. It slows down every once in a while but my programs don't crash any more.
edit: "For example, If you have a 256MB system (shows as 262MB due to 1024 vs. 1000 KB size difference) and have 130MB of apps and data/cache loaded, then that leaves about 130MB for the system to actually RUN programs. That sounds like a lot, but in reality that is not enough, since the system itself takes 50-80MB, and services will take up another 30-50MB, leaving almost nothing. "
quick review, you don't appear to be differentiating between RAM and Flash? Having more apps installed shouldn't increase RAM usage at all. Unless I gravely misunderstand the Android OS, if I install a new program, it resides in the system flash, not the RAM, until I run it, at which point it gets loaded to RAM. When the system needs memory and no swap or Compcache is in use, it writes the state of the application to the flash and removes it from RAM.
Click to expand...
Click to collapse
At first I thought the same way you did, until I started looking in "diskusage".
According to diskusage, there is no separate RAM. 256MB is 256MB. App storage is where everything goes, and what's left is used to load services and such. The numbers I added up matches. I have 256 MB phone. 100 is for apps, which leaves about 150-160. System itself takes 50-80 (acore, gapps, phone, system...) then add a few services and you're down to 30-40 MB free to actually run the programs. The numbers seem to match up to what's shown at the bottom of "Manage Services".
I know it's weird, but perusal of Android developers kit doesn't contradict this understanding.
What the swap does is similar to what compcache does-- compresses apps that are currently in RAM, and moves them to the swap space. In the case of Compcache, this is in the RAM. But since you're compressing it, background apps don't take nearly as much RAM, and you get an app switching speedboost because the processor can uncompress the compcache'd program, "move" it to RAM, compress the currently running program in RAM, and "move" it to the compcache. Forgive me if you already said this, I can't read the entire thing at the moment.
As for swap, I'm not sure if the processor compresses before going to the hard swap file, I don't think that it does-- when android starts getting low on RAM, it moves what was in RAM, to the swap on the SD-card. Since it does this when the system is low on RAM, and not when the system runs out of RAM, you never notice it. Reading the app back from the SD card happens almost instantaneously, because the sd cards can be read from at a speed of at least 20MB/s, maybe more. When you're restoring an app to RAM, 20MB/s is plenty.
edit2: I'm sorry but this guide is too vague to be anything more than moderately informative. Comments like:
-"CompCache, or "compressed cache", is handled by the Linux kernel. It takes a portion of your memory, and use it as a cache space, but compressed. By using on-the-fly compression it is able to make your memory appear to be a bit larger than it actually is. However, the result is slower performance.
This is usually NOT tweakble without mod ROM such as Cyanogen Mod. The kernel also must support this feature, and not all do. This also slows your phone. "
-"...swap space by either creating a swap file or a swap partition. This adds a lot of read/write action to your SD card and may substantially decrease its usable life."
-"This really slows your phone."
People wouldn't be doing these things for no reason. Compcache does not "make your memory appear a bit larger", when it at least doubles the amount of usable RAM-- when you allocate 60MB, if you average 75% compression (I usually see between 65% and 80%), do you know how much RAM this effectively nets you? Over at least 60MB extra, usually about 80! So my phone goes from having 256MB ram to having 340 effectively. Having your processor overclocked minimizes any slowdown from the compression/decompression; I haven't noticed any slowdown, and having the "extra" RAM definitely has made my phone more able to multitask.
Click to expand...
Click to collapse
It also seriously depends on your SD card. I've read reports on Phandroid that said class 6 or 8 microSD cards would provide almost lag-free swaps, but that's on a G1 (which is already a slow phone).
You basically discourage users from doing ANYTHING like swapping, compcaching, etc to their phone, saying it "slows it down" and "can substantially decrease your SD Card's life". My experience has been otherwise regarding slowing it down, and regarding the SD card, the only part that would actually go bad is the swap partition. If you put that at the end of the drive, when it goes bad, you'll know, and you can just move the partition back 300MB and put your 300MB swap there. We haven't heard of any users' cards going bad from this yet. Also, if you have a class 6+ SD Card, they implement wear leveling on the card, so you don't need to worry about wearing out any individual bits.
Sorry, I'm just not digging it.
Click to expand...
Click to collapse
Constantly reading and writing the file will cause that area to get much heavier use and eventually cause it to fail the bootup "checking SD card". The only question is how much life is taken away.
I am running my Droid on 24% CompCache AND 128MB Swap right now. Occasional lag but otherwise runs quite well. It's also overclocked to 1.2 GHz with P3Droid's kernel. So I do practice somewhat of what I preach...

so if I have 512MB of ROM, and 256MB of RAM, and I fill up my ROM with programs, how much RAM do I have?
I don't follow how what you said can be.
SD Card writes-- SanDisk guarantees theirs for 100K writes to any given sector...that's good enough for the swap to not be a problem in the near future IMHO.

let's put it this way...
Here's the specs of Moto Droid from Motorola itself (http://developer.motorola.com/products/droid/)
RAM 256 MB
FLASH ROM 512 MB
USER STORAGE AVAILABLE (MAX) 256 MB
So the REST of the ROM clearly is to hold the Android OS itself. The actual programs you can load for running? 256MB. That's app storage.
I've always wondered if there's a way to read the actual ROM contents and enumerate that... But that's for another topic.

Found this useful post: boot process of Android OS
http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html
Furthermore, I noticed that the "built-in" apps (i.e. bloatware) are actually just stuff left in the "system" dir which can only be accessed with root permission. So they are NOT store in "ROM" per se, but more like "part of boot rom".
I have to find explanation on how an app is loaded, but that helps...

Aha, so that's the term they used... Application Lifecycle.
http://www.youtube.com/watch?v=ITfRuRkf2TM
Okay, I take back what I said. Apps are loaded into RAM, but HOW things are allocated wasn't that clear.
From what I understand, apps, when they are killed by system, some exit gracefully by writing their instance "state" (data and cache) to app storage. Some just exits.
Browser will write the URL, for example. When the browser is "resumed", the process is loaded, then the instance loads back the URL and it's as if nothing happened.
I'll have to revise the paper, AND I haven't figured out what to say about swap and compcache yet.

Made some corrections.
On 256MB machine, 30MB is used by deep system buffers (not part of OS), another 32 for OS cache, so about 190 or so is available the OS itself to load apps and services, and just the default gapps, system, phone, and so on is about 60MB. So a fresh clean phone should ahve no more than 120-130 MB free. If you load a couple apps with autostart services, it'll quickly drop below 50MB.
http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-of-my-application-in-android

Another piece of the puzzle... The numbers at the bottom of "Manage Services" is as explained below:
(quoting from http://android-developers.blogspot.com/2010/02/service-api-changes-starting-with.html )
"Finally, along the bottom of the screen are some obscure numbers. If you know how to interpret them, this gives you a lot of information on the memory status of your device:
* Avail: 38MB+114MB in 25 says that the device has 38MB of completely free (or likely used for unrequired caches) memory, and has another 114MB of available memory in 25 background processes it can kill at any time.
* Other: 32MB in 3 says that the device has 32MB of unavailable memory in 3 unkillable processes (that is, processes that are currently considered to be foreground and must be kept running)"
The order is reversed in Android OS 2.2. Mine says
Other: 75MB in 5 Avail: 18MB + 20 MB in 3
Which should mean 75MB in 5 unterminable tasks, 18 MB free (or can be freed easily), plus another 20 MB used by 3 processes that can be killed to free up.
ProCrank says...
39911K System_server
15756K acore
12982K swiftkey
10136K DIY Screensaver (lock screen)
9392K Phone (system)
9093K ATKfroyo
6834K Terminal
3984K JuiceDefender
3785K Screebl
3482K system MMS
3329 SeePU
3244K Bluetooth
3199K SetCPU
1979K Zygote (which is Dalvik init)
1425K Mediaserver
and the rest is native system code well under 1MB in size.
If you add System_server, Phone, Zygote, Acore, and foreground app (terminal and procrank) you get about 75MB. It would be nice if that screen TELLS you which program it considers to be unterminable, but, oh well...

[Q] Need technical review of "Guide to Android OS Memory Management"

Otherwise known as "Why Newer Android Phones Don't Need Task Killers".
This is straight ASCII cut-and-paste from my Evernote page, so any spelling and grammar mistakes are mine. I have looked over various apps such as AutoKiller, Advanced Task Killer, various threads on memory management in Android, even a few bits of Android source code. I know about compcache, minfree, swap, kernel, and more.
This is aimed at an Android owner who knows the basics, but is trying to optimize their device. They may have experimented with ROMs and kernels based on recommendations, but don't know about serious internal tweaking.
I realize what I wrote will probably have the techies screaming "no, no, that's not quite right"... That's why I want a tech review. If I had committed any serious misunderstandings, please let me know. If you have more references, please list them. Would prefer a bit more detailed comments than "sucks" or "great".
-------
Memory Management in Android: the myths and the facts
Introduction
The Android OS, now at V2.3 "Gingerbread", is widely misunderstood, due to lack of hardware specifications and the open nature of system, has created a wide set of myths regarding how the memory is managed, and how one can best achieve good performance on an Android device.
This article will attempt to explain just how Android OS manages memory, dispel some myths regarding Android memory, and show you some techniques that will help you keep your system running smoothly while achieving good performance.
However, first, here's some technical stuff about Android memory and applications. Trust me, all this is necessary to understand how the whole thing works.
Android OS Memory Management Basics
Android OS, as of V2.2 (and 2.3) have two general types of memory: internal storage (sometimes known as application stroage), and SD card (which may be flash memory that works like SD card, but not physical SD card, such as in the Nexus S)
All apps (in the form of APKs) are loaded into internal storage. Each program can also request additional space as "data" and/or "cache".
All apps (in the form of APKs) are loaded into "app storage" part of the "ROM" (actually flash RAM). Part of the ROM is the boot ROM which loads the system. The other half of the ROM is "app storage". For example, in Motorola Droid, 256MB is RAM, and 512MB is ROM. Out of 512MB ROM, 256MB is Android System itself (actually a bit less), and the rest is "app storage", to max of 256MB.
With Android 2.2 and "Move2SD", a portion of the APK can be moved onto the "SD card", but main portion must remain in internal app storage. The size of the main portion that stays would depend on the app. Some apps cannot be moved or will not function if moved. "Protected" apps cannot be moved. Apps that primarily consist of a service and a widget may not work if moved. add Services or widgets needed for startup should not be moved.
For example, If you have a 256MB system (shows as 262MB due to 1024 vs. 1000 KB size difference) and have 130MB of apps and data/cache loaded, then that leaves about 130MB for the system to actually RUN programs. That sounds like a lot, but in reality that is not enough, since the system itself takes 50-80MB, and services will take up another 30-50MB, leaving almost nothing.
addedIn a 256MB RAM phone such as my Moto Droid, AutoKiller shows...
acore : 4.55MB (system)
dialer: 8.95MB (system)
system: 20.38MB (system)
autokiller:5.68MB
messaging: 3.41MB (system)
Swiftkey: 6.59MB
JuiceDefender 4.14MB
Calendar Storage 4.1 MB (system)
acore: 7.7MB (different pid) (system)
smart taskbar 3.81 MB
seePU 3.44MB
Screebl 4.38MB
SetCPU: 3.83MB
ATK Froyo 3.01MB
gapps: 7.79MB (system)
and 2 more at 4.66MB and 3.56MB
That adds up to... 99.88, or 100 MB.
But that is supposed to leave 156MB, right? Wrong. The system itself takes about 100 MB by itself, in addition to loaded programs, according to this thread about T-Mobile G1 (which has 192 MB of RAM, and has about 96000 KB after booting)
UPDATE: I found an article that explains how to read "MEMINFO". You can get MEMINFO app, or if you have SetCPU the overclocking widget it shows MEMINFO as well. Mine says roughly:
MemTotal: 231740 KB, or 226MB
MemFree: 3376
Buffers 272
Cache: 34960
SwapCache: 0
So the system (before OS kernel) uses about 30MB leaving about 226 MB
Cache itself used another 35 MB. , leaving about 189 MB
Minus 100 MB of auto-loaded apps, and you get... 89 MB.
If you run any programs that need more than that, programs and services will be killed to make room.
(see Redhat's explanation on what meminfo is supposed to mean)
SIDEBAR: native vs. Dalvik
There are two types of Android programs... "Native" programs, and VM programs.
Native programs are written for the specific CPU in the machine. While this gives better performance, this is much harder to achieve, so most people write program for the VM, or "Virtual Machine".
A "virtual machine" is basically a CPU emulator. You feed it a program, and it will run this program, as if it's a real CPU. The good thing about using a VM is it doesn't matter what the actual physical CPU the device uses. You write the program once, and never have to worry about converting it to other CPUs.
Android's VM is called Dalvik, and it is similar to Java's virtual machine. (In fact, Sun/Oracle sued Google for violating Java copyrights on JVM)
Different pieces of a single app
Most apps have either just an activity, or activity along with a service.
"Activity" is basically the user interface that takes your inputs and displays something back. Foreground app would be an activity.
"Service" is a background program that updates something. Common services includes input, widget updates, mail notification, and so on. Other services include Bluetooth, network updates, and so on.
(Actually there are two more types: broadcast receiver, and content provider, but those are not that pertinent to our discussion)
An app can use a widget, and the widget can use a lot of memory, usually several MB at once. You can see the different services and how much memory they are taking under Settings / Applications / Manage Services
How Services Use Memory
As explained above, Android OS have to run programs from within the limited space available, which, on older phones, isn't much. From within that much memory, it needs system work space to load all the services (you probably have a dozen loaded, taking up at least 30 MB) System itself uses about 60-70 MB (acore, phone, gapps, messaging, etc.) That's 100 MB used. That doesn't leave much memory for anything else, if you have 100 MB of apps loaded. (256-100-100=56) 100MB for system itself, about 100MB used for apps and services, and you got almost nothing left.
If you look at the services screen, at the bottom, there's a bar: red, yellow, and green. There is a number in the red section and some in green. Your services adds up to the number in the green section. The yellow portion is some memory that can be freed. The red stuff are system stuff and can't be moved.
What Happens When System Runs Out of Memory
When the system needs to load programs, but don't see enough available, it will start killing programs and services (to the system, they are all considered "process") from memory based on the following priority:
Empty App: the app is in standby, not being used, but is still in memory. These can be killed without any effect.
Content Provider: process that provides content to the foreground, such as "contacts content provider", "calendar content provider", and so on. Various "storage" are also content providers. Those can be restarted when needed.
Hidden Application: apps not visible, but still running in the background. These are not exactly running, so killing them should have no serious consequences.
Secondary server: services that stay in background and apps such as Launcher (or other home replacements). Most services go here, like music player, clock updater, background sync, and so on, that's not built into the OS. If these are killed there may be some problems, such as the playback is interrupted, background sync stops, widget no longer updates, and so on.
Visible app: the app is running and visible, but due to multi-tasking or such is not currently "on top". Any program with a display in the notification area is considered "visible". Android OS will not kill these programs unless absolutely necessary, but it can happen.
Foreground app: you see this app on screen, currently running, but also includes the system itself and "phone". These are never killed. In any case, system and phone have much higher priority than any app to make sure those are never killed.
Each category above has a certain number associated with it, sometimes known as a "minfree" value (in either "pages" or megabytes, depending on the app). When Android OS free memory drops below the minfree value for that category, apps in that category are killed. The killing starts Empty App group as that has the highest number. if that's not enough, it then starts killing apps in the Content Provider Group, and it keeps going until it has finally freed up enough memory to load the app and all related processes (such as services).
NOTE: Having a constant "notification" in the notification area makes the program "visible app" instead of "hidden app", thus making it less likely to be killed by the system to make room for other apps.
A lot of problems with Android device occur when the system tries to make room by killing "secondary server" processes that are needed. Playback of audio (music or podcast) stopped, download stopped, location services stopped... etc. This especially happens on phones with little RAM. First Android phone, T-Mobile G1 / HTC Magic, has 192MB of RAM. Moto Droid have 256MB of RAM. Second generation of Android phones, like HTC Wildfire, got 384MB of RAM. Recent phones, like Droid X, Galaxy S, and so on got 512MB.
NOTE: Some apps, like web browser, can exit but still save the URL you were browsing. So when the process reloads, it is almost as if it was never unloaded. Unfortunately not all apps can do that.
So what is the solution?
There are two approaches to the problem: make more memory available, or pre-empt the auto-kill by killing apps yourself.
Making More Memory Available
There are four ways to make more memory available short of exchanging the phone for a more powerful one.
1) Free up more app storage / internal storage
Either uninstall the apps altogether, or move2sd as much as possible. Keep in mind move2SD may not work for all apps, and amount that can be freed varies greatly. Uninstall an app is best, as it both frees up the space itself takes, and if it loads a service, that service is loaded either, saving even more space.
While it's true that the app that wasn't run won't take up any space, every widget is served by a service, and a small app can load a HUGE service by calling existing libraries and declare a large buffer for downloads. And just because you don't actually use the app doesn't mean the system will not load it. The only way to make sure the app will NOT be loaded is to uninstall it (or if you have Titanium Backup premium, you can "freeze" the app)
2) VMHeap
VMHeap adjusts the the amount of memory that can be dedicated to the Dalvik Virtual Machine (VM). In general this should not be touched, and does not really make more memory available. It is available only for experimentation purposes.
This usually is NOT tweakable without mod ROM such as Cyanogen Mod. And benefits are unproven so far. Don't change anything yet.
3) CompCache
CompCache, or "compressed cache", is handled by the Linux kernel. It takes a portion of your memory, and use it as a cache space, but compressed. By using on-the-fly compression it is able to make your memory appear to be a bit larger than it actually is. However, the result is slower performance.
This is usually NOT tweakble without mod ROM such as Cyanogen Mod. The kernel also must support this feature, and not all do. This also slows your phone.
4) Swap file or partition
Linux kernel allows the OS to use the SD card as swap space by either creating a swap file or a swap partition. This adds a lot of read/write action to your SD card and may substantially decrease its usable life. However, it is a reliable way to "add" a lot of memory to your system.
Root access is required to swap the kernel, and the kernel must support this feature as well. Not all do. This really slows your phone. Beware.
Pre-emptive Killing of Tasks
The other way to avoid auto-kill is to kill the processes yourself via an app, so the auto-kill is not triggered. This is why apps like Advanced Task Killer and all the other "task killers" are created.
Basically, the task killers automate the task of killing apps, so it will free up memory thus auto-kill is NOT triggered. And because Task Killers have ignore lists, you can add your specific app to be ignored, and hopefully it will still run.
The best known one is ATK (advanced task killer) by ReChild, but there are plenty of others on the market. They usually have tweakable settings, like killing apps every time the screen is turned off (eeks!) or just at timed intervals (every 30 minutes), and so on.
On a phone with 512MB (or more) of memory, there should be no need for task killers, as the phone should not run out of memory. On phones with 256MB or less of memory, ATK may be necessary to keep the phone "free" for other apps.
Recommended Actions
If you have one of the older phones with little memory (256MB or less), load only the bare minimum of apps you need. uninstall the rest. You need to minimize your memory usage as much as possible to leave as much space for the apps. Keep 100-150MB available for the system is best. After system and services loaded, there should be at least 50MB left to load other programs and such.
You can use archivers like Titanium Backup or AppMonster to archive the apps to SDcard, and only reactivate them when you need them. Or you can delete them altogether, only redownload them from the Market when you need them. This will even work for purchased apps.
You can also purchase Titanium Backup which allow you to "freeze" apps, which makes leaves them in memory but NOT loaded. You can also uninstall built-in apps that you don't use, such as Amazon MP3, saving even more space.
If that is not enough. you can try using CompCache and/or Swap. However, those are not exactly recommended, and thus are only methods of last resort if you can't kill enough apps to matter. Try 18% compcache or even 26% compcache. If that doesn't help, try 128MB swap, or even 256MB swap if that still doesn't help.
For phones with 384MB or more RAM, you should not have to be so stingy, but no need to overload either. With extra 128MB -384MB you can load extra 50-100MB of apps and a few more services. The idea is still to keep 100-200MB available (depending on the phone). You do not need task killers and all that.

I was looking on the explanation for OOM priorities, and there it is. Thanks. I'm wondering why there are no replies to this thread. Oh wait, it's a question.

thanks for the most awaiting tutorial abt RAM.n yes i was wonderng y this thread hasnt got applause...