Develop Reference

android:Graphics memory is extremly high

The bug is reported by someone else, I have no idea the steps, but got the meminfo dumped, and the hprof file.
It seems the Graphics taking about 1G bytes.... From the android doc, it says Graphics is
Memory used for graphics buffer queues to display pixels to the
screen, including GL surfaces, GL textures, and so on. (Note that this
is memory shared with the CPU, not dedicated GPU memory.)
So how app caused taking so much graphics buffer, does because app have hold some bitmaps I dont know?
The memory leak shown by the hprof file is much less than 1G bytes.
Any clues about the Graphics high memory comsumption?

Is there a limit for TextureAtlas size?

I am new in game development and want to develop a phone game. I am trying to make a complex animation in libgdx, which consists of nearly 300 images (655 × 1160 each, together in size of 42MB). Is there a limit in how big textureAtlas image can be or how many pictures it takes? Will there be a problem if I render 7 animations at once, while 2 of them are as complex as this one (activated skill), but others are just simple character movements?

The atlas can be as big as you have RAM for. The more RAM you have, the bigger atlases you can load.
On Android, you may have problems loading 42 MB big images as it's a lot of allocation at once. There have been multiple posts on Stack Overflow about just that problem. You just have to try loading it and see what happens. If the game crashes with an OutOfMemoryException, you have to make it smaller.
Because Android is a platform with a lot of variation in hardware (some devices have 512 MB total ram while others have 6 GB) there's no "hard limit" to what you can load in on a platform basis. It depends on what device and how much RAM is available (free RAM)Disclaimer: this answer is old and doesn't represent a realistic RAM distribution anymore. With certain phones having as much as 16 gigs of RAM and most flagships boasting at least 4 GB, 42 MB shouldn't (realistically) be a problem anymore. Android RAM allocation is still one of the weirdest systems in existence, and sufficiently large bitmaps may throw an exception separately. Bitmaps in this case do mean through the Bitmap class in "regular" android, and not directly OpenGL and/or LibGDX.
What the TextureAtlas actually contains (complex animations of 30 images vs 2 massive images) doesn't matter. As long as you load it (and manage to get it into memory without the game crashing) there's not going to be a problem rendering it. The framerate may drop though (depending on hardware and how much you actually render) but unless you render thousands of images at once it shouldn't be a problem
Adding android:largeHeap="true" in the manifest is also helpful.

Very high "Maximum memory use" for libgdx game

I've developed a game with libgdx. I've tried to keep memory consumption as low as possible by doing the following:
Use Pooling where possible.
Limit SpriteBatch's size
When I run the game on my phone (Nexus 5x) from Android Studio, my game runs smoothly and it seems that memory consumption is indeed reasonable: The memory consumption is usually under 23MB (I see this via the memory monitor). However, when I go to the memory tab on my phone (Settings --> Memory --> Memory used by apps) I see the following:
A shocking "Maximum memory use" of 1.2 GB for my game. Way above any other app.
My question(s):
What does this number mean? Does this mean that at one point my game took up 1.2 GB of the RAM?
How can that be if the memory monitor never showed a consumption of over 25MB?
Seeing that the game does run smoothly should I try to get this number down? If yes, how can I do this?

You're mixing up native memory (RAM, as shown on the screenshot) and VM memory.
In the memory monitor, you only see the heap (so the memory that was allocated for the VM on which your app is running), but not the actual RAM. This maximum heap size is limited by the system (see e.g. https://stackoverflow.com/a/9940415/1096567 for examples).
Libgdx is using OpenGL via a JNI and is therefore also using the RAM directly.
To investigate your RAM usage in general you need other tools than the Memory Monitor, see e.g.:
How do I discover memory usage of my application in Android?
I don't know your app, but 1.2GB seems a bit high. If you're not using Texture Atlases & the Texture Packer, it's probably a good place to start optimizing. Also be sure to dispose all Disposables (like BitmapFont). Here is a detailed list.

Open GL ES memory management

I'm working on an Android app using Open GL ES 2.0. I'm confused about memory management in Open GL.
My questions are:
How much memory is available to the Open GL hardware? Clearly it's going to vary from device to device.
How can I find out how much memory is in use and how
much is left?
What happens if I exceed the memory limits?
What techniques should I be using to unload data not currently being displayed?
I presume I'm going to have to implement some kind of system to unload textures that are not currently in use on an LRU basis, but I'd like some idea of what criteria to use for this.
The app silently dies at some point and I suspect it is because I'm using too much graphics memory.
Currently I'm never unloading textures and I seem to be able to load quite a few - testing on a Nexus 7 I have been able to load 134 1024x1024 RGBA textures, which I calculate to be over 500MB. I presume once the textures have been loaded into graphics memory they take up less space, but that's still a lot, and clearly I have to manage that but I'd like some tips on how to start.

Simply use gles glDeleteTextures
If you run out of memory you will gen GL_OUT_OF_MEMORY error probably. Another thing is to monitor memory usage in Android.
android memory: How do I discover memory usage of my application in Android?
See here an interesting question for opengl: how to manage memory with texture in opengl?

Seemingly inconsistent OutOfMemory crashes on different Android devices

I am making a game which has to load all bitmaps at start because in the in-built game editor the user can put any of the sprites into the level. Also levels use various sprites without any system which would allow to load groups of sprites dynamically for each level.
After a while the are now already 250+ png images in the game with total size of 3.5MB.
The game loads most sprites (about 200) using BitmapFactory.decodeStream without any options set, and also there are about 50 other which are referenced in xml layouts of activities.
When I test on various devices, the game sometimes runs out of memory, but i can't find a pattern and even decide by HOW MUCH i have to, e.g. reduce the size of images or their number.
The phone on which i developed, HTC desire with Android 2.2 24MB VM heap size never runs OOM.
Dell Streak with Android 2.2 and 40MB VM heap size never runs OOM, too.
Motorola Milestone with Android 2.1 and 24MB VM heap size successfully loads all sprites but chokes on the few last images used in ImageView's when starting one of the activities (start menu). If I comment a few of such ImageViews out, it loads ok, but may choke on one of the other activities later. It's also not stable, probably because fragmentation happens differently in different launches.
HTC hero with 2.2 of my buddy (dunno the heap size, is it 16MB?) crashes as well.
What's most confusing is that Motorola has 24MB, the same as HTC desire. Is 2.1 implementing memory management less efficiently? (e.g. leads to more fragmentation?) Or is memory management worse by all Motorola phones? Then why does HTC hero with 2.2 crash? What's bigger in HTC desire than HTC hero?
Looks like OOM happens on older phones, but that's the only thing I've figured out so far.
If OOM only happens on older phones which are, say, 5% of the market, I can just exclude 2.1 or a more specific list from the supported devices by just gathering crash reports and excluding all that crashed from the list of supported. Otherwise I'd now need to scale down all my images by some constant factor (e.g. 1.6), which would mean resizing all the 45 levels which took days and days of designing and testing, repositioning GUI elements etc. Even after that, I'd still not be sure, on which devices the reduction of total size of bitmaps by a factor of e.g. 2 is enough to avoid OOMs.
Any advice on this?
Should I set any specific options for BitmapFactory? btw, most images have transparent bg pixels which, as far as i understand, doesn't allow getting them in 565 format.
I spent 2 days browsing here and in other places but am still at a loss.
Thank you.

I've had to deal with a simpler version of your problem - we had 3 2Mpix layers on top of each other, which, unsurprisingly, sometimes caused OOM.
In my case, instead of using 3 ImageViews on top of each other, keeping all 6 MPix in memory at all times, I manually blended the layers, thus keeping at most 4 Mpix in memory at any one time (and only 2 MPix at "rest" - the layers changed in our application).
This is a classic time-space trade-off - sacrifice efficiency (time) to gain memory (space). It was somewhat slow because you had to recycle() each Bitmap after you were done with it to ensure the memory was freed.
As for the inconsistent OOMs, it probably has to do with garbage collection. You can assume that the garbage collector is non-deterministic and thus any memory pressure becomes non-deterministic as well (depending on when the GC last kicked in).
The short summary is, you have to be very, very careful with your memory usage and there's no way around it. *
* In theory, you could allocate memory outside the Dalvik heap by using the NDK and allocating straight from the OS. It's a huge hack and the bridge between Dalvik and your allocator will be rather ugly.

First you need to find what exactly is using all of your memory. Check this out. Maybe you could be recycling bitmaps, for instance.