android: memory for kernel and apps

by Porting beginner » Fri, 12 Mar 2010 03:47:01 GMT

Sponsored Links

I have android running on my target platform.
When its booting, as kernel boots , I see free memory around 53mb-55mb range
there till console.
( cat /proc/meminfo )

*Just after kernel boot...

MemTotal:          88792 kB
*MemFree:           53496 kB
*Buffers:               0 kB
*Cached:            24028 kB*

But once android services/apps starts and reach to idle screen, most of
memory cached
*Once reach to Idle screen*

MemTotal:          88792 kB
*MemFree:           23228 kB ( keep changing in range of 23mb to 27 mb )*
*Buffers:              44 kB
*Cached:            20700 kB ( keep changing 19mb-25mb )

After this, if there is memory request from app , it seems android manage to
get it from cached

As I start more and more apps, free mem decrease and cached mem increase but
after exit from app, mem still hold as cached
mem and not all mem return as free mem.

And  if there is request from kernel space ( from some driver module ,
kmalloc or kalloc ), it seems its not going through and request failing.

Any idea ? is that generic behavior of android ?



android: memory for kernel and apps

by Uat H1 » Mon, 15 Mar 2010 20:59:00 GMT

 It's usual on Linux (where Android comes from), while the system has
free memory it caches every access to storage devices to improve later
access to same data.
When the system needs memory for a process the cached memory is
immediately available if needed, the system will discard or save on
disk some of the cached content and use the new free memory for the
demanding process.
You nearly may consider cached memory as free memory.


Sponsored Links

android: memory for kernel and apps

by Dianne Hackborn » Tue, 16 Mar 2010 02:16:22 GMT

 On top of that, Android also keeps live processes around as a cache, even if
they are not currently doing anything.  These will be killed by the Android
Patented Viking Killer as part of the cache eviction when more memory is

> website: 

Other Threads

1. A suggested way to deal with long running tasks across context switches.

I was e{*filter*}d to see the introduction of the AsyncTask. Anything to
make the division of UI / Background work easier is good in my book.

What bugged me was that I couldn see a way to keep a long running
process alive during a context switch e.g. a layout orientation
change. As far as I could see, the common way to olvethe problem
was by stopping the process and then recreate it in the new Activity.
This will work in some cases, but in others it won work. For
example, a background task of creating a new user account on a website
cannot be re-sent easily.

I spent a day and hacked out an alternative way of doing things. My
approach was this.

    * We know that the AsyncTask contains a Context which is the
Activity that creates it. So it must be destroyed when the Activity is
destroyed e.g. at a context switch due to a screen orientation change.
    * Since we want to background task to continue crossa context
switch we cannot define the background task within the AsyncTask.
Instead we create a Future and pass that to some implementation of
AsyncTask that only wait for the Future to compute.
    * At a context switch we can destroy the AsyncTask without
interrupting the Future which we can hold on to.
    * When creating the new Activity post-context switch we create a
new fresh ASyncTask and give it the same still running Future.

The easiest way to understand this is to see it in action. I've
uploaded an example implementation of the above idea to:

You're free to check it out and make use of it as you please. If you
do use it though, I'd appreciate if you'd let me know just so I can
get that warm fuzzy feeling of having helped someone out. If you have
comments or suggestions, again, I'd like to know.


Gustav a.k.a. Parakoos

2. NullPointerException : String imageFileName = myFile.imageFileName.toString(); when imageFileName is null

Seriously, this never ever worked:

String imageFileName;
String theString = imageFileName.toString().

Calling toString() on a null object has always and will always result in a

Dianne Hackborn
Android framework engineer

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.


3. trouble with Contacts groups

4. How to handle tall dialogs

5. TabWidget problem

6. Drawing on the incoming call screen

7. android emulator window hangs when closing window