This post is the result of providing solution for the ISSUE 'bitmap size exceeds VM budget' if Activity is restarted' filed at http://code.google.com.... click here ..... .

According to Andreas(who filed this bug), he tried to create and discard the image in the 'onCreate' method of app's Activity and if the Activity is restarted (because of the orientation changes or anything else check it here...)

Andreas's code is below, here he is creating 10 bitmaps...



Now, run the app but it blasts....


The reason of this is... allocation of the memory for PNG Image file(size 262.1 KB) that is converted to Bitmap is more frequently rather than the freed memory done by the DalvikVM's default GC routine, so before the GC do something the app has already gone.... :-(

This type of problem always comes when we play with Images in Garbage Collected environment like JVM (J2ME apps) and in this case Android app.

To handle this issue basic approach is make the recourses or objects 'null' and call 'System.gc()', Let's use this approach in this scenario...for that remove the final keyword from the 'InputStream is' and remaining as follows...

And it works fine, check it  below...


WE THINK it is GOOD!
But check my another approach below....


And the output of this is below...

Without GC calls it is working like a charm!!!
Yes, Android provides an api 'recycle()' for bitmap object. Let's see how does this api works...
________________________
Implementation of 'recycle'...

 public void recycle() {
        if (!mRecycled) {
            nativeRecycle(mNativeBitmap);
            mNinePatchChunk = null;
            mRecycled = true;
        }
    }

________________________
This method do a JNI call to a native api 'nativeRecycle'. 'nativeRecycle' is mapped to call another native method called 'Bitmap_recycle'.

{   "nativeRecycle",            "(I)V", (void*)Bitmap_recycle }

________________________
Implementation of the Bitmap_recycle...

static void Bitmap_recycle(JNIEnv* env, jobject, SkBitmap* bitmap) {
    bitmap->setPixels(NULL, NULL);
}

________________________
Here the method 'setPixels' is called to do the hardwork....

void SkBitmap::setPixels(void* p, SkColorTable* ctable) {
    this->freePixels();
    fPixels = p;
    SkRefCnt_SafeAssign(fColorTable, ctable);

    SkDEBUGCODE(this->validate();)
}
_________________________
Implementation 'freePixels' is below ...

void SkBitmap::freePixels() {
    // if we're gonna free the pixels, we certainly need to free the mipmap
    this->freeMipMap();

    if (fColorTable) {
        fColorTable->unref();
        fColorTable = NULL;
    }

    if (NULL != fPixelRef) {
        if (fPixelLockCount > 0) {
            fPixelRef->unlockPixels();
        }
        fPixelRef->unref();
        fPixelRef = NULL;
        fPixelRefOffset = 0;
    }
    fPixelLockCount = 0;
    fPixels = NULL;
}

and implementation of 'freeMipMap'...


If your see above, in the 'freePixels' method it free the colortable, unlock the the pixel address for an existing bitmap then free the memory.

Conclusion: For Android specific we should use the 'recycle' method rather than 'gc', because 'recycle' will free the memory at the same time, but calling 'gc' doesn't guaranty to run and free the memory for same time(if it is not too critical, we should not call gc in our code) and results can very every time.
One more thing using 'recycle' is faster than the 'gc' and it improves the performance.

Update: "If we don't call recycle on the bitmap then it is GC's responsibility to free that, but in actually the timing for automatically call of GC to do this is uncertain and that make things worst. It is not bitmap's or any other object's responsibility to say hey i am done now they call or trigger GC. in other words it is not a bitmap or any other object's bug but...we can say that it is a GC optimization algorithm's bug while CPU is fully in use(that for loop) and missed the right timing ... and that is too late for that app. so as a partial responsibility we should call recycle or gc in our code, in that case recycle is best to use while GC comes with side effects."

Inputs are welcomed...

Happy Coding...