Android Question Can't catch OutOfMemoryError

[kiki78]

I have screen capture method inspired form http://www.b4x.com/android/wiki/index.php/Tricks_Of_The_Trade.

Public Sub GetScreenShot() As Bitmap
    Try
        Dim r As Reflector
        r.Target = r.GetActivity
        r.Target = r.RunMethod("getWindow")
        r.Target = r.RunMethod("getDecorView")
        Dim W As Int = r.RunMethod("getWidth")
        Dim H As Int = r.RunMethod("getHeight")
        Dim Out As Bitmap : Out.InitializeMutable(W, H)
        Dim Cnv As Canvas : Cnv.Initialize2(Out)
        r.Target = Cnv
        r.Target = r.GetField("canvas")
        Dim args(1) As Object : args(0) = r.Target
        Dim types(1) As String : types(0) = "android.graphics.Canvas"
        r.Target = r.GetActivityBA
        r.Target = r.GetField("vg")
        r.RunMethod4("draw", args, types)
        Return Out
    Catch
        Return Null
    End Try
End Sub

Some time I receive OutOfMemoryError

java.lang.OutOfMemoryError
    at android.graphics.Bitmap.nativeCreate(Native Method)
    at android.graphics.Bitmap.createBitmap(Bitmap.java:640)
    at android.graphics.Bitmap.createBitmap(Bitmap.java:620)
    at anywheresoftware.b4a.objects.drawable.CanvasWrapper$BitmapWrapper.InitializeMutable(CanvasWrapper.java:587)
    at b4a.example.graphictools._getscreenshot(graphictools.java:40)
    ...

I put the code inside Try-Catch to try to intercept OutOfMemoryError, but I continue to receive it.
Is it normal ?
What is the good procedure ?

Parallel question : Is it possible to increase VM memory allocated to application in B4A ?

Regards

 

[Informatix]

OutOfMemory is not an exception; it's an error. You have to catch it specifically and it's not possible with B4A.

There's a debate about the handling of errors and unchecked exceptions (e.g. NullPointer, IndexOutOfBounds, etc.) in Java. Some people think that errors and unchecked exceptions should not be caught as they should not happen if the program is well written, others think the contrary, especially for the OutOfMemory error (sometimes it happens even when you did your best to prevent it and it's better to try to recover from it than to crash the app).

 

[Informatix]

I submitted this in the past and Erel said no.
Note that's not as easy as you think to recover from an OoM; it depends on the case.

 

[kiki78]

Thank you both.
So, if I write my method in java library, may I catch it ?
I'm not really easy for now with that, but last week I compile my first wrapper for Java library and it's not as hard as I imagine.

 

[Informatix]

Thank you both.
So, if I write my method in java library, may I catch it ?

Yes.

try {
}
catch (OutOfMemoryError OoMe) {
}

 

[kiki78]

Thank you Informatix,

I will try that.

Best Regards

 

[Erel]

The solution in this case is to avoid the out of memory issue at all. It should be quite simple.

All you need is to create the bitmap and canvas once and reuse them.

 

[kiki78]

Thank you Erel.

My problem is I keep some of this image to present it to user for selection and eventually save in file.
I maintain last image in List and use Add to add new image and RemoveAt(0) to remove old.
Is shared bitmap and canvas for capture help to save memory in this case, as I need to copy it ?

 

[Erel]

You can create a smaller copy of this image with createScaledBitmap and then reuse it.

 

[kiki78]

That's a possible solution.
Thank you Erel.

 

[Informatix]

It still amazes me why the Android O.S. is so stingy with memory. Most devices now have 512MB, or 1 GB Ram or more.

On an Android phone, it's very common that a dozen applications or services run concurrently (antivirus, email app, agenda, google play, facebook, system services, etc.). If your device has 512 MB and you want to be able to run up to 16 apps on this device, then you have to restrict the memory to 32 MB to each program. This way, you're sure that two or three programs will not steal all the memory.
For very hungry apps like games, this limitation is mainly for the code as the textures and buffers are not in the Java heap. And when you run a game, it is the front app, so it can get all resources if needed.
The Google's choices make sense but I agree they were frustrating with the old generations of phones and tablets because of the low amount of memory on these devices.

to load a 2 MB HDTV (1920x1080 pixel) still image into a bitmap unless it was reduced in resolution.

8,3 MB in memory (1920x1080x4)

In conclusion: Erel please spend some time on adding automatic recovery to B4A after an OOM error, if indeed possible.

Automatic recovery is not possible. Only you, the programmer of the app, can know what to do in such a situation. And as I said above, even when you catch an OoM error, recovering from it is not always an easy task (imagine that you're loading a game background and you get a OoM; you can only display a message and close the app; you cannot continue with a black background or a very low resolution image).

 

[Erel]

In conclusion: Erel please spend some time on adding automatic recovery to B4A after an OOM error, if indeed possible.

There is an automatic recovery. It works when you load bitmaps from files (this is not the case here). The bitmaps are downsampled if there isn't enough memory.

 

[Informatix]

There is an automatic recovery. It works when you load bitmaps from files (this is not the case here). The bitmaps are downsampled if there isn't enough memory.

For me, it's not a good solution as the downsampled image is hardly usable in some (most?) cases because of the important difference with the original image. I agree that trying to prevent OoM is better than using a LargeHeap and catching the error, but sometimes you cannot do anything else than handling the error and you want to do something better than displaying a "patch of colors" barely recognizable.
Calling this "an automatic recovery" is a bit exaggerated IMHO.
My 2 cents.

 

[kiki78]

Thank you all.
I'm starting to go to the Dark Side, and try to understand if and where I made memory leak.
If you have some advice to help me, your are welcome

 

[Erel]

If you have some advice to help me, your are welcome

1. Use the same mutable bitmap and canvas each time.
2. Create a smaller image by calling CreateScaledBitmap.

 

[Informatix]

Thank you all.
I'm starting to go to the Dark Side, and try to understand if and where I made memory leak.
If you have some advice to help me, your are welcome

To see your memory usage, you can use the Monitor tool provided with the Android SDK. Otherwise, you can also rely on the functions of my Cache or StrictMode libraries to know the used and free memory at a given time.

 

[kiki78]

Thank you Informatix
I'm starting to use Monitor since this morning.
For now I can connect to my device, but I can't see process.
In Console I see this message

[2014-04-10 10:28:50 - hierarchyviewer]Unable to get view server version from device 192.168.0.158:5555
[2014-04-10 10:28:51 - hierarchyviewer]Unable to get view server protocol version from device 192.168.0.158:5555
[2014-04-10 10:28:51 - ViewServerDevice]Unable to debug device: samsung-gt_n8010-192.168.0.158:5555
[2014-04-10 10:28:51 - hierarchyviewer]Missing forwarded port for 192.168.0.158:5555
[2014-04-10 10:28:51 - hierarchyviewer]Unable to get the focused window from device 192.168.0.158:5555

Some advice ?

 

[Informatix]

Adding the SET_DEBUG_APP permission and setting android:debuggable to true in your manifest may help.

 

[kiki78]

Thank you Informatix.
This solve my problem