Develop Reference

How to get the total amount of memory used by OpenGL in mobile devices?

I've found the answer for desktops, but I could not find anything for Android/iOS (assume I can use up to OpenGL ES 3.0). So this is the same question for mobile devices: Is it possible to get the total memory in bytes used by OpenGL by my application programatically?
Note: I am OK with a non-universal solution (AFAIK universal solution does not exists), but something that works at least on popular devices (iOS/Snapdragon/..)

No, it's not possible via any standard API.
Most graphics drivers will account any graphics memory to the process, so you can always use the "top" command line utility to get total process memory. It's not able to isolate the graphics memory, but it should give you an idea how how much your process is using in total.
That said, you probably have a pretty good idea how much data you uploaded/allocated storage for using the GLES API, which is probably a good finger in the air estimate for total memory. Most of the bulk storage related to application assets.

Estimation of "CPU", "CPU Load" and "Memory_Usage" for an Android app

We are using Trepn to get the "CPU", "CPU Load" and "Memory_Usage" of some andriod app.
Please see the attached screenshot for the Memory Plot generated in eclipse.
My Question is, though my phone is in idle state, trepn is showing 1.7GB of memory usage.
Can someone tell us why is it taking that much memory though no other application is launched.
Also, Is there any way to relate this value (1.7GB) to my application to tell if this value is acceptable or it is using more?
We came accross the formulae for calculating memory from trepn site:
Memory Usage = (number of pages the application has in RAM) * (page size) / (total available RAM)
Can some one explain how is this page(s) calculated?

Proper memory management in OpenGL on Android devices

We have an app where we draw many things (mostly OpenStreetMap Tiles but also other images) with OpenGL ES 2.0. This works pretty good, but from time to time the app crashes without any information - this means: The app just closes, not a message that it is crashed and also there is no message in logcat.
From experiments we've figured out, that the app crashes after loading too many textures into OpenGL (glGenTextures/glBindTexture)
In an experiment on a Samsung galaxy S3 we are able to load up to 1800 textures with a size of 256x256 in RGB888 standard. After that our app crashes without any error logs. Shouldn't we receive an error(GL_OUT_OF_MEMORY) when we are constantly checking for OpenGL Errors (GLES20.glGetError) while loading textures?
Generally asked:
Is there a way to determine the maximum size available in gpu memory or at least, how do we get a warning as soon as we are running out of memory? (The problem is we do not know WHEN we should start deleting handles and we want to keep most of them as long as possible...)
Thanks in advance for any replies.

So after some research we found a solution.
But first of all:
These methods won't help and either won't these.
The methods mentioned in the first post will get you absolutely useless numbers which won't help you at all and may not even be correct (since my galaxy S3 got a much higher number than a nexus 7. But in our tests the nexus 7 could load the same amount or even more textures than the S3).
Then let's move on to our solution - which we are still not sure is the best, but it will work:
It look likes you can keep as many textures in OpenGL as you have free total RAM. Yes total RAM, not heap and not something other related to your app! It's really the amount of free RAM of your whole system, there are NO restrictions!
So once you figure that out you just read out the amount of free RAM you have:
ActivityManager actvityManager = (ActivityManager) mapView.getActivity().getSystemService( Activity.ACTIVITY_SERVICE );
ActivityManager.MemoryInfo mInfo = new ActivityManager.MemoryInfo ();
actvityManager.getMemoryInfo( mInfo );
Log.v("neom","mema " + mInfo.availMem/1024/1024);
Best place to do that is probably in your onSurfaceCreated method or somethign like that.
The amount of memory you get there is the total free RAM you currently have. Mostly this value is too low, in almost any case you can even allocate more memory than you get there (in our tests we could always allocate about 30%-50% more RAM than the availMem gave us until the app crashed (tested on Nexus 7 (+28%), Galaxy S3 (+36%), Transformer T1 (+57%), Nexus S (+57%))). Reason for this is: Android will free memory from unused stuff, background processes and so on, before it really runs out of memory.
So what does this mean?
You can (almost) safely keep as many "bytes-of-textures" in OpenGL as you have free RAM. For example: Lets say you have 375 MB free RAM and textures which each have a size of 256kb, you could keep about 1500 Textures in OpenGL before you start deleting some of them (with an LRU cache or something like that). You could even keep more, but I think you are pretty safe with this amount.
Sureley you could also get the availmem more frequently and just fit your cache size or what ever you are doing to this new amount of memory - but I think it suffices if you do it once in onSurfaceCreated - especially since this will be read out again if you switch to another app and back.

Guideline for memory usage in C/C++ on Android

On android.com they say, that if you're working in Java, the maximum memory you can use is 16 MB. At least that's the one the devices are supposed to support. If you have an older phone, you'll notice that you can't get more, you get an OutOfMemoryError instead. Not if you're doing the same thing using the NDK. In on of my applications I am trying to get 50MB and more, and so far Android was fine with that.
I havn't found anything related to that on android.com.
Is there any limit like in Java, too?
If yes: what's the limit?
If no: What is a good value for that?
Problem is, that I have to build my code depending on that size.
[Edit:]
I tried what Seva Alekseyev were suggesting.
root#android:/ # ulimit -a
ulimit -a
time(cpu-seconds) unlimited
file(blocks) unlimited
coredump(blocks) 0
data(KiB) unlimited
stack(KiB) 8192
lockedmem(KiB) 64
nofiles(descriptors) 1024
processes 7806
flocks unlimited
sigpending 7806
msgqueue(bytes) 819200
maxnice 40
maxrtprio 0
resident-set(KiB) unlimited
address-space(KiB) unlimited
root#android:/ # ulimit -v
ulimit -v
unlimited
root#android:/ #
The memory I am requesting (by using "alloc" or "new") is virtual memory (ulimit -v). So there's no chance to figure out how much I can gain?!

You're subject to three types of memory limits:
1) Artificial limits put in place to keep the system responsive when multitasking -- the VM heap limitation is the main example of this. ulimit is a potential mechanism for a the OS to provide further limitations on you, but I have not seen it being used restrictively on Android devices.
2) Physical limits based on available real memory. You should have a baseline device you're developing/testing on, and should be pretty aggressive in assume other processes (background services, other apps) need memory too. Also remember that memory in use by the OS varies with OS version (and will tend to increase over time). Stock Android doesn't swap, so if you go too far you're dead. One potential scenario is a Nexus One (512MB RAM) with an audio player and the phone app going in the background, and a "balloon" service eating another 100MB physical memory to give some leeway; in this configuration you'll still find more than 100MB available.
3) Virtual memory limits based on address space. Stock android allows overcommitment of memory, so it won't blink if you ask for a 1GB virtual allocation (via mmap, etc) on a device with 512MB of RAM, and this is often a very useful thing to do. However, when you then touch the memory, it needs to be brought into physical memory. If there are read-only pages in physical memory they can be ejected, but soon enough you're going to run out, and without swap -- dead. (The combination and overcommit and no swap leads directly to process death in out-of-memory situations, rather than recoverable errors like malloc returning null).
Finally, it's worth noting that whether calloc/malloc/new require physical allocation is allocator-dependent, but it's safer to assume yes, especially for allocations less than a large number of pages. So: If you're dealing with < 100 MB of standard, well behaved allocations, you're probably in the clear -- but test! If you're dealing with large amounts of data that you'd like memory mapped, mmap is your friend, when used carefully, and is your best friend when used with PROT_READ only. And if you're dealing with > 100 MB of physical memory allocations, expect to run quite nicely on modern devices, but you'll have to define a baseline carefully and test, test, test, since detecting out-of-memory situations on the fly is not generally possible.
One more note: APP_CMD_LOW_MEMORY exists, and is a great place to purge caches, but there's no guarantee it's called in time to save your life. It doesn't change the overall picture at all.

Why does my android app have a maximum RAM limit as 64 MB?

I'm developing an android app that has a lot of bitmaps that uses a lot of RAM. My question is that when I keep my app running for a long time and the ram usage exceeds 64 MB, the app crashes with an "OUT OF MEMORY ERROR, VM won't let us allocate ... etc".
While other apps such as facebook reaches 200 MB ram sometimes without any crashes and with a very fast performance. My device is Galaxy S II.
and please notice that my question is not about reducing the memory usage, it's about the difference in memory limit between my app and other apps.
Thanks.

I think there is a limit on the amount of memory that an application can use... Used to be 32MB... There might be a permission that you can change to request more memory, in the same way that you can request hardware acceleration. From a quick google android:largeHeap="true" might be your answer... Also Runtime.getRuntime().maxMemory(); might help? This link was also interesting...

The amount of memory that the vm is reserving for each application is not part of the Android ecosystem and can't be determined, it's part of the configuration given by the manufacturer.
Usually the last word about the memory size for each vm is given by the file build.prop.
Do not use the NDK trick if you do not know what are you doing.