[Resolved] Problems saving/loading photos from album on android

Solar2D Android
#41

Joshua, I am already doing all that.

As I said, it is not only my game, but the Corona Photo Picker Sample app.

So, what you are saying is that Photo Picker app cannot be used more than 10 times, what does not make sense at all…

Imagine I am telling you that your Instagram app can only post 10 photos and after that it will restart… actually, it would only work only 2-3 times since Instagram has a lot more assets than the Photo Picker…

In addition, I don’t think that this is a out-of-memory issue since:

  1. There is not memory warning being shown

  2. I am printing here the textureMemoryUsed before going to the Album and it always prints “textureMemoryUsed= 0” (I made a simpler version of the Photo Picker without any assets, just touch to open the Album and show the image on screen)

 

But being honest with you, I am not even wanting a whole fix for that… I only want a work-around to make this works…

UPDATE: Since the system is killing the app, it is expected to be an out-of-memory issue. But all current indicators are not showing any sign of out-of-memory, so I only see 2 options:

  1. It is not out-of-memory problem

  2. There is some memory leak that is not being captured by available indicators (memoryWarning event,  textureMemoryUsed,…)

UPDATE 2: I forgot to mention a important info. One of my users said that the game was working fine before and after an update it started the problem (he can only open 1 image per session). And I also was only able to reproduce this error recently. So, I conclude that this bug may be introduced in some daily build…

#42

I’ll have someone double check if there is a memory leak issue… because that PhotoPicker sample app always removes the previous image before showing the Photo Gallery.  It’s either that or the garbage collector is being really lazy and we might have to force garbage collection manually to free up memory.  I’ll get back to you on this later today.

#43

Thanks Joshua.

I will also try to track what build this issue started to happening and I will let you know.

#44

Okay, so, we were able to reproduce this issue.  We are definitely detecting a slight memory leak everytime you suspend/resume an app and after doing this enough times, the app exceeds the max heap limit on Android.  We think we’ve isolated this issue in our core C++ code, which unfortunately means we can only fix this in a daily build.  Also, theoretically, this issue should only happen on Android and Windows.  Mac and iOS may not have this issue.  This also looks like a graphics 2.0 issue as well.  We’ll investigate this further and let you know once we have it resolved.  Thanks for bringing up this issue.

#45

Hi Joshua.

Yes, that makes sense specially because the system kills the process after it is suspended…

Just let us know which daily build the fix will be when you have it.

Thanks for checking this out Joshua.

#46

Yes, please do that… I already mentioned that last year…

http://forums.coronalabs.com/topic/36744-android-app-quits-when-go-to-cameraphoto-album-need-to-read-system-variable-to-solve-it/

#47

I still have this problem too since long time ago… All my android apps reboot randomly when I load a photo from gallery.

I am using version 2269 and still happens. It doesn’t happens when I take a photo, only when I load from album

#48

So, this bug of the app crashing when going to Photo Album is still happening with me and is making users leave a lot of bad reviews of my game…

I finally was able to reproduce it and this bug is also happening on the Corona Photo Picker sample. I just need to select like ~9 photos and on the 10th the app restarts…

It appears that the system is killing the process even having 51% of free memory… here is a extract of the log:

03-19 14:26:39.962: D/dalvikvm(676): GC\_EXPLICIT freed 166K, 51% free 3173K/6471K, external 1596K/2108K, paused 97ms 03-19 14:26:39.993: W/GLThread(19105): onSurfaceCreated 03-19 14:26:39.993: I/RenderView(19105): OSC 03-19 14:26:40.005: D/LocalDataSource(19105): registerContentObserver 03-19 14:26:40.083: D/MediaFeed(19105): Thread End 03-19 14:26:40.091: I/RenderView(19105): \>\>\>\>\>OSC 03-19 14:26:40.091: W/GLThread(19105): onSurfaceChanged(480, 800) 03-19 14:26:40.091: I/RenderView(19105): First Draw 03-19 14:26:40.142: I/GLThread(19105): sending render notification tid=128 03-19 14:26:40.145: I/MediaItemTexture(19105): Decoding Start 03-19 14:26:40.145: I/MediaItemTexture(19105): Decoding End 03-19 14:26:40.145: I/MediaItemTexture(19105): Decoding Start 03-19 14:26:40.149: I/MediaItemTexture(19105): Decoding End 03-19 14:26:40.153: I/MediaItemTexture(19105): Decoding Start 03-19 14:26:40.153: I/MediaItemTexture(19105): Decoding End 03-19 14:26:40.157: I/MediaItemTexture(19105): Decoding Start 03-19 14:26:40.161: I/MediaItemTexture(19105): Decoding End 03-19 14:26:40.208: I/MediaItemTexture(19105): Decoding Start 03-19 14:26:40.212: I/MediaItemTexture(19105): Decoding End 03-19 14:26:40.212: I/MediaItemTexture(19105): Decoding Start 03-19 14:26:40.212: I/MediaItemTexture(19105): Decoding End 03-19 14:26:40.220: I/MediaItemTexture(19105): Decoding Start 03-19 14:26:40.220: I/MediaItemTexture(19105): Decoding End 03-19 14:26:40.224: I/MediaItemTexture(19105): Decoding Start 03-19 14:26:40.227: I/MediaItemTexture(19105): Decoding End 03-19 14:26:40.282: I/ActivityManager(523): Process com.redbeachgames.renato.PhotoPicker (pid 19078) has died. 03-19 14:26:40.282: I/ActivityManager(523): Low Memory: No more background processes. 03-19 14:26:40.282: I/WindowManager(523): WIN DEATH: Window{40954908 SurfaceView paused=false} 03-19 14:26:40.290: I/WindowManager(523): WIN DEATH: Window{409d1c50 com.redbeachgames.renato.PhotoPicker/com.ansca.corona.CoronaActivity paused=false}  

Any ideas to solve that?

UPDATE: Since this thread is with “RESOLVED” in the title, I am opening a new one here: http://forums.coronalabs.com/topic/45599-app-being-killed-by-android-while-at-album/

#49

It’s not a bug.  It happens if the end-user checks on the Developer Option “Don’t keep activities”.  This makes the operating system destroy the last shown activity when displaying a new activity, such as the photo album.  In Corona, this would trigger an “applicationExit” event.  From a native development stand-point, this also prevents the Activity.onActivityResult() method in Java from getting called, making it *impossible* to know which photo was selected.  But that said, this is a Developer Option on an Android device that is not accessible to most end-users.  The Developer Options menu has to be unlocked.

Regarding loading over 10 camera photos crashing your app, that’s because your app ran out of memory.  Apps are not given all of the RAM that is available on the device.  They’re is a maximum heap limit that an app can use, which varies between devices (the limit is set by the device manufacturer).  Now, Corona always checks if we’ve successfully allocated the memory needed for the image when decoding an image file and surrounds everything with try/catch blocks, but that said, OutOfMemory errors can’t always be caught reliably.  I find that some forks of the Android OS, such as the Xperia Play, just flat out kill the app when attempting to decode a PNG or JPEG giving zero opportunity to handle it gracefully.

If you’re running out of memory, my best advice is to:

  • 1st, avoid loading too many large images on Android.  There are too many cheap low-end Android devices out there, making this extremely risky.  We already have a ton of safety mechanisms in place, but there is only so much we can do.

  • 2nd, add the “largeHeap” setting to your “build.settings” file.  But just note that not all devices honor this setting and Google recommends avoid it.

   http://docs.coronalabs.com/guide/distribution/buildSettings/index.html#large-heap

#50

I am using the Corona Photo Picker app on a Galaxy S. I am pretty sure that this problem will happen on your test devices there also…

On the Corona Photo Picker it takes 9-10 times to show the error. On my game (that has other assets) it only takes 2-4 times…

So, can i assume that there is some memory leak problem in the media.SelectPhoto function?

In addition, I added a memoryWarning listener and it is not being called anytime… 

When the app opens (after being killed) coming from the Gallery, it shows some errors also (I don’t know if they have useful info…)

03-19 14:26:41.681: I/ActivityThread(19377): Pub com.redbeachgames.renato.PhotoPicker.files: com.ansca.corona.storage.FileContentProvider 03-19 14:26:41.727: D/dalvikvm(19377): Trying to load lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/liblua.so 0x40514a98 03-19 14:26:41.735: D/dalvikvm(19377): Added shared lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/liblua.so 0x40514a98 03-19 14:26:41.735: D/dalvikvm(19377): No JNI\_OnLoad found in /data/data/com.redbeachgames.renato.PhotoPicker/lib/liblua.so 0x40514a98, skipping init 03-19 14:26:41.735: D/dalvikvm(19377): Trying to load lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libjnlua5.1.so 0x40514a98 03-19 14:26:41.739: D/dalvikvm(19377): Added shared lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libjnlua5.1.so 0x40514a98 03-19 14:26:41.743: D/dalvikvm(19377): Trying to load lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libjnlua5.1.so 0x40514a98 03-19 14:26:41.743: D/dalvikvm(19377): Shared lib '/data/data/com.redbeachgames.renato.PhotoPicker/lib/libjnlua5.1.so' already loaded in same CL 0x40514a98 03-19 14:26:41.743: I/dalvikvm(19377): threadid=1: recursive native library load attempt (/data/data/com.redbeachgames.renato.PhotoPicker/lib/libjnlua5.1.so) 03-19 14:26:41.743: D/dalvikvm(19377): Trying to load lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libopenal.so 0x40514a98 03-19 14:26:41.770: I/OpenAL\_SLES(19377): alc\_opensles\_init 03-19 14:26:41.770: D/dalvikvm(19377): Added shared lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libopenal.so 0x40514a98 03-19 14:26:41.770: D/dalvikvm(19377): Trying to load lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libmpg123.so 0x40514a98 03-19 14:26:41.782: D/dalvikvm(19377): Added shared lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libmpg123.so 0x40514a98 03-19 14:26:41.782: D/dalvikvm(19377): No JNI\_OnLoad found in /data/data/com.redbeachgames.renato.PhotoPicker/lib/libmpg123.so 0x40514a98, skipping init 03-19 14:26:41.782: D/dalvikvm(19377): Trying to load lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libvorbisidec.so 0x40514a98 03-19 14:26:41.782: D/dalvikvm(19377): Added shared lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libvorbisidec.so 0x40514a98 03-19 14:26:41.782: D/dalvikvm(19377): No JNI\_OnLoad found in /data/data/com.redbeachgames.renato.PhotoPicker/lib/libvorbisidec.so 0x40514a98, skipping init 03-19 14:26:41.782: D/dalvikvm(19377): Trying to load lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libalmixer.so 0x40514a98 03-19 14:26:41.786: D/dalvikvm(19377): Added shared lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libalmixer.so 0x40514a98 03-19 14:26:41.786: D/dalvikvm(19377): No JNI\_OnLoad found in /data/data/com.redbeachgames.renato.PhotoPicker/lib/libalmixer.so 0x40514a98, skipping init 03-19 14:26:41.786: D/dalvikvm(19377): Trying to load lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libcorona.so 0x40514a98 03-19 14:26:41.958: D/dalvikvm(19377): Added shared lib /data/data/com.redbeachgames.renato.PhotoPicker/lib/libcorona.so 0x40514a98 03-19 14:26:42.298: D/libEGL(19377): loaded /system/lib/egl/libEGL\_POWERVR\_SGX540\_120.so 03-19 14:26:42.321: D/libEGL(19377): loaded /system/lib/egl/libGLESv1\_CM\_POWERVR\_SGX540\_120.so 03-19 14:26:42.337: D/libEGL(19377): loaded /system/lib/egl/libGLESv2\_POWERVR\_SGX540\_120.so 03-19 14:26:42.427: D/dalvikvm(19377): Note: class Landroid/opengl/GLWrapperBase; has 211 unimplemented (abstract) methods 03-19 14:26:42.431: V/GLSurfaceView(19377): glGetString(7937) returns PowerVR SGX 540; 03-19 14:26:42.474: V/Corona(19377): \> Class.forName: network.LuaLoader 03-19 14:26:42.474: V/Corona(19377): \< Class.forName: network.LuaLoader 03-19 14:26:42.474: V/Corona(19377): Loading via reflection: network.LuaLoader 03-19 14:26:42.477: I/Corona(19377): Platform: GT-I9000 / ARM Neon / 2.3.6 / PowerVR SGX 540 / OpenGL ES 2.0 03-19 14:26:42.759: V/Corona(19377): \> Class.forName: CoronaProvider.licensing.google.LuaLoader 03-19 14:26:42.759: V/Corona(19377): \< Class.forName: CoronaProvider.licensing.google.LuaLoader
#51

The issue here is that the operating system is force quitting your app because it is using too much memory.  There’s nothing not much we can do about it.  And we already go well out of our way to avoid this low memory situation by unloading all images/textures from memory when a Corona app gets suspended to avoid this very issue, because it used to be a common issue a few years ago with older memory-starved devices.

So, you really have no choice other than to redesign your app to consume less memory.  I recommend the following:

  • When selecting a photo from the gallery, have it saved to file instead of displayed.

  • When displaying all photos in your app, only display smaller thumbnails of the images which consume less memory.  You can do this by reducing the scale of the photo and then doing a display.save() on them.

  • Only display 1 photo at a time in your app at full resolution.  Free it from memory via removeSelf() and collectgarbage() in Lua before loading the next large photo.

#52

Joshua, I am already doing all that.

As I said, it is not only my game, but the Corona Photo Picker Sample app.

So, what you are saying is that Photo Picker app cannot be used more than 10 times, what does not make sense at all…

Imagine I am telling you that your Instagram app can only post 10 photos and after that it will restart… actually, it would only work only 2-3 times since Instagram has a lot more assets than the Photo Picker…

In addition, I don’t think that this is a out-of-memory issue since:

  1. There is not memory warning being shown

  2. I am printing here the textureMemoryUsed before going to the Album and it always prints “textureMemoryUsed= 0” (I made a simpler version of the Photo Picker without any assets, just touch to open the Album and show the image on screen)

 

But being honest with you, I am not even wanting a whole fix for that… I only want a work-around to make this works…

UPDATE: Since the system is killing the app, it is expected to be an out-of-memory issue. But all current indicators are not showing any sign of out-of-memory, so I only see 2 options:

  1. It is not out-of-memory problem

  2. There is some memory leak that is not being captured by available indicators (memoryWarning event,  textureMemoryUsed,…)

UPDATE 2: I forgot to mention a important info. One of my users said that the game was working fine before and after an update it started the problem (he can only open 1 image per session). And I also was only able to reproduce this error recently. So, I conclude that this bug may be introduced in some daily build…

#53

Hi Joshua.

Do you have any update on the fix for the memory leak? I was going to release a new update on the game and just noticed that the bug is still there. (Tested on last daily build - 2014.2275 - both on Photo Picker sample app and on my game).

Thanks,

Rebato

#54

I’ll have someone double check if there is a memory leak issue… because that PhotoPicker sample app always removes the previous image before showing the Photo Gallery.  It’s either that or the garbage collector is being really lazy and we might have to force garbage collection manually to free up memory.  I’ll get back to you on this later today.

#55

Thanks Joshua.

I will also try to track what build this issue started to happening and I will let you know.

#56

Okay, so, we were able to reproduce this issue.  We are definitely detecting a slight memory leak everytime you suspend/resume an app and after doing this enough times, the app exceeds the max heap limit on Android.  We think we’ve isolated this issue in our core C++ code, which unfortunately means we can only fix this in a daily build.  Also, theoretically, this issue should only happen on Android and Windows.  Mac and iOS may not have this issue.  This also looks like a graphics 2.0 issue as well.  We’ll investigate this further and let you know once we have it resolved.  Thanks for bringing up this issue.

#57

We think we’ve narrowed it down to a bug in Google’s GLSurfaceView class in Java, because when we grabbed the newest version of that class from GitHub (Google open sources most of the Android OS), the memory leak went away.  However, in doing so, it introduced some new issues that prevented us from making that change.  Unfortunately, this issue still requires quite a bit of experimentation on our end to find a solution.  We don’t have an ETA yet.

#58

Hi Joshua.

Yes, that makes sense specially because the system kills the process after it is suspended…

Just let us know which daily build the fix will be when you have it.

Thanks for checking this out Joshua.

#59

Ok. Thanks for the update.

#60

Ok, just considere please that while that bug is public our apps are getting more and more low rating and complains. Please, fix it, please!