Develop Reference

Recycle Bitmap in loop

Here look at the below code,
for (String path : all_path) {
bmp = BitmapFactory.decodeFile(path);
bitmapList.add(bmp);
}
and this code is driving me crazy. As in each iteration BitmapFactory.decodeFile(path) is called and driving memory to its pick as a result OutOfMemory exception occurs. I tried to use recycle() old bitmap in the loop before decoding new bitmap but it means no sense. I searched for the answer about using bitmaps in loop but failed to find one. What should I do? anyone help please.

You are adding all bitmaps to a List. However you are using the same reference variable bmp for all bitmaps so in each iteration they get replaced.
But in the List all the bitmaps are being added. If there are many bitmaps then it will eventually result in OutOfMemoryError
Better do not add all bitmaps in a List.

Try to recycle the bitmaps you are not using.
If you use all the bitmaps than add them to a cache and use them later.
Next when you want to replace one you will replace just one not all of them.
The change from below requires a bit more work but it works as I used it with a lot of bitmaps.
Please take a look here:
I implemented once something like this:
http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html

Bitmaps can be huge. Why do you need to read them all to the memory? Normaly, you would read each bitmap on demand. Optionally, you can read thumbnails, which are much less memory demanding (BitmapFactory enables you to downsize the bitmap when reading - use BitmapFactory.Options, member inSampleSize).
Read this: http://developer.android.com/training/displaying-bitmaps/index.html

Android - bitmap operations, keep source bitmap or use second bitmap and recycle source

One would think that the second approach would be more efficient but I can't say that I see any improvement using it. Is there a difference between the following two ? (memmory wise ofcourse)
Bitmap bm=MediaStore.Images.Thumbnails.getThumbnail(getContentResolver(), id, MediaStore.Images.Thumbnails.MINI_KIND, null);
bm=cropAndScaleBitmap(bm);
//use bm
vs
Bitmap bm=MediaStore.Images.Thumbnails.getThumbnail(getContentResolver(), id, MediaStore.Images.Thumbnails.MINI_KIND, null);
Bitmap b =cropAndScaleBitmap(bm);
bm.recycle();
//use b

Things to note here ...
Even though you have specified recycle, it will have any effect only
when the next GC is trigerred.
Other things to note
In pre-Honeycomb versions of Android the memory for bitmaps was (is) allocated from unmanaged memory.It will take at least 2 passes of GC to collect it. Another thing is - it is really difficult to trace - DDMS does not see it and neither does MAT.
Read this link https://developer.android.com/training/displaying-bitmaps/manage-memory.html. If api level >10,I don't think we need to call recycle.
Refer to this link ... It provides all details and the code sample for how to implement step by step.
https://developer.android.com/training/displaying-bitmaps/manage-memory.html
Hope this helps.

In your specific example (first one) you don't actually reuse the source, you just overwrite the value of the bm making it point to the new bitmap instead, in this case you can no longer call recycle on the source bitmap as you no longer have a reference to it.
I recommend using the second method to make sure the source bitmap is recycled.

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.

What's the better way to use getResources() many time in Android

Im my app, i use alot of getResources() like that
BitmapFactory.decodeResource(getResources(), resourceid, opts);
i can use Resources res = getResources() as Global variable and use
BitmapFactory.decodeResource(res, resourceid, opts);
So, my question is: What's the better way to avoid memory leak?
Thanks

I do it this way on occasion which I think can be fine but you just have to watch it. In your situation, I'm not sure that its worth creating a Global variable when nothing is changing. I will do it for a function to get a certain resource depending on context or some other variable. But here, I don't see how
BitmapFactory.decodeResource(getResources(), resourceid, opts);
is any better than
BitmapFactory.decodeResource(res, resourceid, opts);
It seems that you are adding one extra unnecessary step

I wouldn't try to micro optimize this too much, just use common practices about creating less garbage where possible. By this, I mean avoid decoding something, and letting it go out of scope and decoding it again.
Really, unless you keep decoding huge images or something like that, I don't see any problems.

How To Fill Bitmap Data in ARGB Format in Android LabelView

I'm working with Android and I really need a fast way to get a bitmap of format BGRA to be filled in ARGB.
One thing I aslo want to let u know that The Data comes in byte[] format and I have to convert in int[] format also.
Can AnyOne Tell me How to do this ...
Thanks in Advance

If you want to load a Bitmap by bytestream, you can use Bitmap.decodeStream. You could then use getPixel(s?) to get the int array. This is one way I know how to do this, probably not the fastest though. A faster way would be to convert bytes to int, if your byte array is nothing but pixeldata this won't be too hard.
BGRA to ARGB can be done with bitshifting quite fast.
A nice source you would probably like:
https://web.archive.org/web/20141229164101/http://bobpowell.net/lockingbits.aspx

The fastest way I think would be to do it in native code using the NDK. I've been considering to use it for image processing for some time but didn't get the chance yet. So I don't know much about it (i.e. how you would access your byte buffer) but you could start from the Plasma sample for bitmap processing in JNI.