Technical Details of Android Garbage Collector

Is Android garbage collector pausing other apps while running?

The Dalvik VM in the Gingerbread and beyond version is using the Mostly Concurrent partial collection garbage collector with pause times usually around 5ms. Therefore, yes, the GC is influencing the other apps by stopping them but the concurrent GC algorithm is able to minimaze these pauses.

You should look at :

Technical details of Android Garbage Collector
Does the DalvikVM Garbage Collector halt the whole VM?

In general, the Garbage Collection theory [Garbage Collection Wiki] explains:

Stop-the-world garbage collectors completely halt execution of the program to run a collection cycle
Incremental and concurrent garbage collectors are designed to reduce this disruption by
interleaving their work with activity from the main program. Incremental garbage collectors
perform the garbage collection cycle in discrete phases, with program execution permitted between
each phase (and sometimes during some phases).
Concurrent garbage collectors do not stop program execution at all, except perhaps briefly when the program's execution stack is scanned.

Garbage collector in Android

For versions prior to 3.0 honeycomb: Yes, do call System.gc().

I tried to create Bitmaps, but was always getting "VM out of memory error". But, when I called System.gc() first, it was OK.

When creating bitmaps, Android often fails with out of memory errors, and does not try to garbage collect first. Hence, call System.gc(), and you have enough memory to create Bitmaps.

If creating Objects, I think System.gc will be called automatically if needed,
but not for creating bitmaps. It just fails.

So I recommend manually calling System.gc() before creating bitmaps.

Generic Android Garbage Collection

I'm not sure your information is correct.

It collects class system classes.

No. It collects instances of objects that are no longer reachable from any of the system roots. System roots include any static reference, any reference from a thread's active stack frame, any active synchronization monitor, and anything held by a native piece of code (global or local). An object is considered live (and hence cannot be reclaimed) if there is a path from it to a root tracing the reference graph backwards. Any object that doesn't not have a path to a root can be reclaimed by the garbage collector. Classes are referenced by a ClassLoader and are never reloaded and hence are not reclaimed by the system unless that ClassLoader is collected and all instances of those classes are collected. So Android never collects class system classes because that ClassLoader is never collected.

It collects items from activity "only" if android manifest file states that the activity is either hasNoHistory or singleTop

No. An activity is nothing more than an instance of an object. And when the reference to the activity is gone so goes all of the references it pointed to unless some other root points to that object. By setting singleTop="true" you are only telling Android to instantiate a single instance of this activity, and all intents sent will be handle by that single instance. It doesn't have any impact on GC. When an activity looses its path to a root it will be reclaimed regardless of what the settings on that activity were.

You may force a garbage collection using "System.gc()" although this is not recommended as it may delete something important class item.

No Garbage collection algorithms do not delete any live object. Under your definition above it implies GC can collect an object you were using which is incorrect. If it did that's a big bug. That is also the beauty of Garbage Collection algorithms in that they are guaranteed to clean up garbage perfectly. If you are running out of memory the programmer has forgotten to remove a reference or you are being careless with your use of memory. The reason you aren't suppose to call System.gc() is that you/your program has no clue when the best time is to reclaim memory. The garbage collector is trying to maximize the ratio of (the time your program runs) vs. (the time it spends collecting garbage). It keeps very detailed statistics and makes estimations about when its a good time to run garbage collection vs simply allocating more memory.

It's like cleaning your house. You can't clean at all times because it makes doing things take longer sometime you have to let it get dirty (Like cooking). However, if you never clean your house it can take all day to clean it. So there is a balance that you must strike between how dirty can it become before cleaning it up takes longer than performing the task.

This is why you shouldn't calculate/guess/force GC in your program because Android has already implemented it for you, and will do a better job than you can ever hope to.

What does this mean for you the developer?

Let Android handle when GC should run.
Clean up references to help the GC know when something can be reclaimed. Be very careful about static references, and never allow a static to hold a reference to an activity, service, etc to one.
Don't allocate lots of small amounts of short lived memory. This will force more GC time to clean up. By allocating memory conservatively you are by definition helping that ratio.

Most of the time GC is very hands off. The only problems developers get into is not establishing boundaries for long living objects vs. UI objects. If a long living objects has a reference back to the UI that's a place you'll have to unregister or else you'll leak memory. It's ok for the UI to hold references to long living objects, but not the other way around.

The real issue with Android is how much you make the garbage collector work. If you keep the amount of memory you are using small then the garbage collector doesn't have big jobs it has to do. That doesn't mean you should reuse objects or create object pools, etc. But, you should be aware of what statements are creating memory, and how long those objects live for.

There are volumes of information on Garbage collection in general and particularly Java's Concurrent Mark and Sweep garbage collector. Android's garbage collector is not as performant, but it's pretty darn good. Most of the time I don't worry about GC unless there is a problem so it's mostly hands off.

And garbage collection isn't a grey area. It's very much well understood, and the industry has expanded the field quite a bit since Java was introduced in 1994.

Difference between Java gc and android gc?

Short answer: There is in fact a difference between garbage collectors in Java and Android.

The reason for that is, that Android does not use the "standard" JVM, it uses Dalvik VM.

You can read some more information about the concept of garbage collection in JVM here. Additionally I recommend the question Technical details of Android Garbage Collector to get some knowledge about the garbage collector concept in Android.

Determine when the Android GC runs

You can do this with a weak reference trick:

WeakReference<GcWatcher> mGcWatcher
        = new WeakReference<GcWatcher>(new GcWatcher());
long mLastGcTime;

class GcWatcher {
    @Override
    protected void finalize() throws Throwable {
        handleGc();
        mLastGcTime = SystemClock.uptimeMillis();
        mGcWatcher = new WeakReference<GcWatcher>(new GcWatcher());
    }
}

Now... whether it is really correct for an application to do this, is another thing. :) The only place I know of anywhere we have done this in Android is the code here, and its sole purpose is to help us be smart about when we ask processes to explicitly GC such as when they go into the background.