To bitmap.recycle(), or not to bitmap.recycle()

Question

A few days ago, we released an app in Play store, which deals with high quality bitmaps and is all about editing them.

Everything was going well when we realized that 20% of devices were giving out of memory errors. So we checked our code and found out that Android was not releasing native memory used to store bitmap data on some devices. In this case, we welcomed the recycle command.

The memory errors disappeared (at least in hd devices). Anyway, we were happy. But today we started to see that 50% of devices started to give another error: "Can't copy a recycled bitmap"

We were bummed. On two bitmap.copy() lines in our code, half of the devices cannot do this two lines in synchronous:

Bitmap anotherBitmap = bitmap.copy( bitmap.getConfig(), true );
bitmap.recycle();

So we removed the recycle and releasing another update, decided to limit the device screen sizes, so small ones do not give us a bad rating.

Here is my question. Why some devices can copy before recycling, and half cannot?

I read Google's bitmap related documentation and already knew how bitmap is stored on both vm's heap and native heap, how garbage collection works on out of memory errors, etc. The example code Google provides to load and edit large bitmaps is nearly same as ours.

Read a lot of blogs, google group threads, github code samples... I think I still need a good documentation/book about Android bitmaps.

PS: We are already using inSampleSize to scale bitmaps while decoding them.

EDIT -- Here are some data from the crash reports:

All devices are non-rooted. In most cases used memory is between 25% and 35%.

Manufacturers: 
57% LG
31% Samsung
10% Casper Via V5 (Turkey based company, sells rebranded Chinese phones)

Devices:
81% LG D855 (G3)
18% LG D802TR (G2)
----
66% Samsung SM N910C (Galaxy Note 4)
20% Samsung SM A700F (Galaxy A7)

Operating Systems:
68% Android 5
31% Android 4

OS 5 Details
69% Android 5.0
30% Android 5.0.1

OS4 Details
66% Android 4.4.2
33% Android 4.4.4

Luisaluise

As far as I can remember if a bitmap is placed in native memory has to do with what version of Android you're running, later versions of Android do not store them in native ram and on those you shouldn't need to call recycle. When it comes to what actually happens when you call copy & recycle it depends on the oem manufacturer and android version, could you supply a bit more information regarding device & platform? – Diseased

One possible course of action could be to only call recycle on phones running ginger beard or earlier (if your data with which phones get the issue supports the idea that the phones with out of memory issues are all running ginger bread or earlier). – Diseased

As for documentation about bit maps, fastest and easiest thing is to check out how aosp does things, some manufacturers do change things around (Samsung being the largest culprit) but it should give you sufficient info about how things are done on most devices, easily searchable aosp: androidxref.com – Diseased

@Diseased just added the crash report details for checking. But as much as I can see the data has no specific device or os version. Some LGs with os 5, some LGs with os 4 are crashing, but some are not. Same goes for Samsung devices. Jelly Bean (4.1) is the min version we support, so no Gingerbreads. – Luisaluise

Answer 1

Are you really sure that for some reason

bitmap.copy(..)

is not called twice?

i.e.:

//first call Bitmap anotherBitmap = bitmap.copy( bitmap.getConfig(), true ); bitmap.recycle();

[...]

// second call Bitmap anotherBitmap = bitmap.copy( bitmap.getConfig(), true ); bitmap.recycle();

Bede

yes. recycle is only used once. we use this first copy for effects. the second copy is created for resetting the edited image, which is created from the first copy, not the original. devices having the null pointer exception are telling that the same line of the same class had the problem. and only ~50% of devices have a crash. remaining has no problem with the recycle. currently we changed our editing workflow and removed recycle all together. most probably we will be moving image reading to ndk for better memory management as android's gb is a mess when it comes to bitmaps. – Luisaluise