Develop Reference

Android not freeing Bitmap from memory

I have done following things to handle my bitmaps in application:
LruCache for Bitmaps with size of 1/8 of memory
Using BitmapFactory.Options to calculate inSampleSize
Catching OOM when creating Bitmaps, calling evictAll and System.gc() there
Also there are AsyncTask decoding sometimes for Bitmaps
I use BitmapFactory.decodeFile and it looks like VM is not freeing Bitmaps fast enough from memory. I read somewhere that there might be bug using BitmapFactory.decodeFile so I tried to use BitmapFactory.decodeFileDescriptor, but there I randomly get following:
skia --- decoder->decode returned false
So is there something wrong with FileInputStream needed to fix here if I wan't to use BitmapFactory.decodeFileDescriptor or something else to do.
This has taken me too much time and I've read all solutions based on this and how Google advices Bitmap handling and I've come to dead end.
Thanks.

Using large Bitmap always there is a chance to get Out Of Memory Exception..
So to handle go through Android blog
http://developer.android.com/training/displaying-bitmaps/index.html
And always recycle the Bimap
ImageView mImage;
Drawable toRecycle = mImage.getDrawable();
if ( toRecycle != null && toRecycle instanceof BitmapDrawable ) {
if ( ( (BitmapDrawable) mImage.getDrawable() ).getBitmap() != null )
( (BitmapDrawable) mImage.getDrawable() ).getBitmap().recycle();
}

I ended up using SoftRefences with Bitmap here. Now I can see GC freeing my unused Bitmaps all the time when fast scrolling GridView which draws them.
Tested setting my LruCache size full memory size and still didn't get OOM.
Penalty using this method is not that visible, my GridView scrolls pretty smoothly considering it's drawing very custom image.

System.gc() won't help you and doesn't guarantee anything.
If you absolutely sure, that evicted bitmaps are no longer needed and there is no reference to them anywhere (will catch "Can't draw recycled bitmap" exception otherwise) I would suggest you to add an EvictionListener to your LRU cache and call bitmap.recycle() on every evicted value.
Can't remember if default LRU cache provides convenience methods for setting eviction listener, but if not, it's extremely easy to extend it and add required functionality.
P.S. I would advice against WeakReferences since you lose any control of your bitmaps and purpose of LRU. Even if you load 8 bitmaps that nicely fit in your 1/8 of memory, but screen can only display 4 of them at a time (ImageViews holding a strong references to Bitmaps) gc will clear remaining 4 as soon as possible. And I really mean ultra fast. You'll have to reload bitmap for each new row (in case of ListView) you are displaying. And every bitmap that went offscreen will have to be reloaded again.

Reference counting android Bitmaps with caches

On Android pre-honeycomb, Bitmaps have freaky memory issues because their data isn't stored in the VM. As a result it isn't tracked or removed by the GC. Instead it is removed when Bitmap.recycle() is called (and that is also done automatically in the Bitmap's finalizer).
This leads to some problems when doing image caching. When a bitmap is due to be evicted, I can't simply call recycle() on it, because I have no idea if anyone else is using it.
My first thought was to do System.gc() just before I load each bitmap. That way, hopefully orphaned Bitmaps will be finalized and the native memory freed. But it doesn't work. Edit: Actually it does sort of work. I had my System.gc() in the wrong place, after moving it, and halving my cache size (to what seems like a ridiculously small 2 MB of uncompressed bitmap data), my app no longer seems to crash (so far)!
My next thought was to implement manual reference counting, by subclassing Bitmap and calling ReferenceCountedBitmap.decrementCount() in all my activities' onDestroy() methods. But I can't because Bitmap is final.
I am now planning a BitmapManager which keeps WeakReference's to the bitmaps, and has methods like:
public void using(Bitmap bm);
public void free(Bitmap bm);
which count the references.
Does anyone have any experience or advice handling this? Before you suggest it, I can't ignore 80% of the market.

Well, I solved this with a bitmap manager, where I save the referencing views. In a map-like structure bitmap -> list of views.
Before I call recycle() on a bitmap, I first set all the references from the views to null (otherwise it will throw bitmap recycled exception).
Manual garbage collection, as you say, doesn't work for bitmaps pre-honeycomb, since they are allocated in the native heap and even with System.gc() you can't make assumptions when this memory will be released.

DDMS Heap - 1-byte array(byte[], boolean[])

I experience some memory leaks in my android application. I've already used MAT to analyze the memory usage. But I have one question from the DDMS perspectiv in Eclipse, what does 1-byte array[byte[], boolean[]) mean?
Is this specific for my application? You can see that this is the big memory leak issue, this always increases in size, and the rest will increase and decrease randomly. My guess is that the GC doesn't catch this type. Can anybody explain why this happen, with this little information?

One byte array is the designation for any data structure that is organized as a single byte array. In you case and with that size, I would bet in a Bitmap or a Drawble.
Most common reasons for memory leaks are static object not properly managed and holding references to:
Context
View (which holds reference to context (and possibly also to bitmap)
Thread (which are not easly collected by GC)
Handler (which holds reference to context)
Most of them can be solved ensuring that you set the object to null when it's no long required.
Regards.

A byte and a boolean are each 1 byte. If you have an array of those you have a "1-byte array".
A ByteBuffer for example should internally hold one of those.
You have a total of 614 of them where the smallest one be a byte[24] (or boolean[24]), the largest one is 3MB. All of them together use 104MB.
The GC will get rid of them if they are no longer referenced.
For example when you put
private static byte myArray[] = new byte[3 * 1024 * 1024];
in one of your classes and never set it back to null (myArray = null) then this one can't be garbage collected because another Object has a reference to it. The object would be the class itself (as in String.class). The class object can't be garbage collected since classes are never unloaded. (they are referenced by their ClassLoader which could itself be referenced / loaded by another ClassLoader and you can't create Objects & use classes without them - they need to stay and they need to keep a reference to their classes)
It's usually not that simple but often start with static somewhere.
Within MAT (after you force GC) look at the reference chain for the objects that are no longer intended to stay alive and identify the one Object that holds the reference. Set that one to null in your code and your leak is gone. Explained in more detail here:
http://android-developers.blogspot.de/2011/03/memory-analysis-for-android.html

I ran to this problem tonight and almost I checked every bit of code but I couldn't find anything.
What I did was starting the app from intelij and then pressing home button and open the app again. Every time the app heap was doubled.
Finally I discover when I launch the app from ADB and press the home button and open the app again it doesn't bring back the old activity, it just start a new one. When I pressed finish it starts to cycle through all of them. It's like they are treated as two different intent. So I put android:launchMode="singleTop" on the main activity in manifest and it resolved the problem.
Although it's not the main cause of this problem but if you encountered this check this out before anything. It wasted three or four hours for me.

Android: keep bitmap in application class

I have big bitmap covering whole screen. After reading a lot of posts about memory leaks and performance I noticed 2 problems:
1. Generating big bmp costs time.
2. Caching big bmp /static bmp in activity/ speeds up activity start, but causes problem with references and memory.
My decision is to move bitmap in Application class.
How will this reflect on references and garbage collection?
Do I have to make bitmap in application class static?
UPDATE:
Please don't comment 'same memory' in both cases. My question is related to references and garbage collecting.

It's not important how you load bitmap when it is in memory.
It still takes the same amount of memory.

Bitmap OutOfMemory on Multiple Screen Changes

I have a bitmap that I load from the SD card by allowing the user to choose a picture to display. Once the bitmap is created, I set the Bitmap in an ImageView:
mBitmap = Bitmap.createBitmap(Media.getBitmap(this.getContentResolver(), mPictureUri));
mImageView.setImageBitmap(mBitmap);
This works fine. But, if I change the screen orientation from portrait to landscape, and back again a few times, I always get an OutOfMemory exception.
In onPause, I call mBitmap.recycle(), and then on onResume, I call the above code again to create the bitmap and set the ImageView. Since I'm recycling the image each time, how can I get an OutOfMemory error?
In any case, since that failed, I found a post that said to try using onRetainNonConfigurationInstance() and getLastNonConfigurationInstance(). See post Save cache when rotate device. I changed my code to work this way, and I still get an error. Changing the code, I had the call to getLastNonConfigurationInstance() in onCreate(), and removed all code in onPause and onResume.
Can someone tell me what the problem is, or provide some way to simply load an image, and then be able to pause and resume the Activity without running out of memory? Thanks.

Try reducing the size of your bitmap. How big is it? Use BitmapFactory.options.
Also instead of using "this instance". See the article about memory leaks:
http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html

The memory leaks could be due to holding on to the context instance which in turn contains references to all the objects from the Activity before it was destroyed.
The article explains it better.
You should reduce size of the images because there is 16MB per app, if you have large bitmaps being recreated, they could accumulate to 16MB before they are garbage collected or if there are memory leaks.