I am actually experiencing a heap problem while using interstitials (2.3 Nexus One).
I am able to reproduce the problem using the admob sample from Google play (android sdk). I have just set my ad id and my device id as a test device (I also have the problem without doing setting the test device id).
Just launch the sample, choose interstitial, Load, Display, Close.
Now in DDMS you can see a given amount of Allocated memory after having triggered the GC. (in my case 3.421 MB)
Then if I keep on repeating the Load, Display, Close operation, I see that the Allocated size on the heap just keeps on increasing. After some launches I reach 3.936 MB, and it never seems to stop.
I DO NOT change the phone orientation in between or do anything fancy.
I have tried changing new InterstitialAd(this) to new InterstitialAd(getApplicationContext()) as suggested in some other questions, but it does not change the problem.
On a 4.4.2 emulator the problem seems to exist too (I say seem because as the emulator is really slow it is hard to perform the operation a big number of times).
Of course I have the same problem with my real application. In my real app I also tried recreating the interstital before each loading (after having removed its listener) but the problem is exactly the same, so my guess is that it is not the interstitial instance itself that leaks, but perhaps the web view, or one of admob threads.
In my real application this causes a crash when loading a "big" bitmap (a 800*560 png) because of a OutOfMemoryError failed to allocate... so I am afraid that this may also leak some native memory (which is used for bitmap allocation in 2.3)
EDIT : It seems to leak some native memory indeed, but a very samll quantity.
Related
I have an app that is doing a lot of work related to Bluetooth connection and displaying graphs etc.
App is using many libraries as well. App has also a background service running all the time. Now I noticed that it is taking upto 500 Mbs of Memory Usage.
What I have done was commented out. Everything on app launch and just showed splash screen (custom made) and still footprints are 60-70 Mbs. That means something is taking too much memory without even using it.
One important thing is that Android Studio's Memory Monitor is showing me that app is using only 40-50 Mbs whereas my phone's Memory manager is showing upto 500 MBs. I have tested this on 3 phones. Result remains same.
Any help should be appreciable.
You are leaking alot of memory you can go to memory monitor in android studio and use garbage collector to have an estimation of the total amount of leak you're having.
Most of the time External libraries are main Issue for the memory leakage due to their differing implementations and are quite inefficient when used for work on mobile client.
Here is a great blog regarding memory leakage.
http://blog.nimbledroid.com/2016/05/23/memory-leaks.html
Use MAT Tool to find out memory leakage and resolve that.
Once started service, if it is no needed then stop the service using intent.
And also check you have started any timer thread and not stopped it.
This is the case when I want to simulate an Out of memory crash in my application. I have a lot of crashes from Crashlytics which indicate that end users are running into OOM crashes and I have not been able to reproduce them with my device (Samsung S4). I just have crashes and no other traces from crashlytics.
I was wondering if someone has a way to reproduce them for their testing (without any code change preferred).
I saw this : Testing Android for Out of Memory scenarios , but haven't got a chance to run it yet.
Any help would be appreciated.
There are a variety of ways to cause OOM.
Use a very large image (incidentally, this use-case is a source of many real OOM issues in apps). I replaced the image for 1 element in my Recycler, so when I scroll to it, it will load the large image (then I can drive the test that way).
Create a loop, that allocates objects to memory. You can just "new" up a bunch of objects in a loop, and run it that way. If you allocate enough Strings, or int objects into a single array, this will run OOM eventually (this is also a good way to gradually build to an OOM condition). Strings will cause OOM faster then ints (but add enough objects to an array, and eventually it will become too large).
I was able to simulate the OOM error by replacing a list of images in the app very large images. 5mb instead of usual 250k. Wikimedia has lot large images you can use. https://commons.wikimedia.org/wiki/File:Snake_River_(5mb).jpg
I hope I'm understanding the question correctly: There's a very easy way if you don't want to change a lot of settings. Go into dev options and make it "no background processeses". Now you can exit out of the app, launch a new one and go back into your original and it'll be wiped out from out of memory
I have an app that has been on the market a while and I have tested the app on multiple devices and played it a great many times without problems. Then recently I tested it on a rather crummy low performance device and got the dreaded "bitmap size exceeds VM budget" error on the very first run. I had this error before with a completely different app, but it only occurred after a great many repeated uses. When I researched this error at the time, I saw the the most up-ticked answers to resolving this issue were in relation to deallocation/garbage collection issues... but presumably it must be possible to run into this error without even having made any coding errors. Surely the error can occur simply by using an underpowered device?... and if it can, how would you distinguish that from a coding error?
Surely the error can occur simply by using an underpowered device?
Not really. An "underpowered device" can display bitmaps, as you can tell just from the home screen. The issue is how big of an image it can display, in terms of resolution and bit depth, and how many such images you can hold in memory at once. You should be using things like getMemoryClass() on ActivityManager to see how big your heap is, then tailor your image processing to match.
I'm making a sketching app, mostly for fun. But i've run into a problem.
Within my app, the user can "flip" through sketches they've already drawn. These sketches are just 400x800 Bitmaps. But i'm constantly running into out of memory errors.
Sketches are saved to SD as soon as the user flips away from them, and they are then deallocated with...
if(bitmap != null)
{
bitmap.recycle();
bitmap = null;
}
So, only one or two Bitmaps should be loaded into memory at any given time, before they are saved and deallocated. And with a few debug prints, i've determined that this is true (max. two bitmaps in memory at the same time). My problem is that after 14 loads/deallocations, the program crashes with an OutOfMemoryError. Always 14, no matter how long i wait between "flips".
I've tried opening DDMS to see what the device's memory allocation is like. Strangely, every time an image is deallocated, memory goes to the "unknown" section, instead of the "free" section. This continues until there is only a sliver of "free" memory left, at which point the crash occurs (and the "unknown" memory goes to "free").
After a lot of googling, i've found a few resources which say that bitmaps should be deallocated as expected, and that Dalvik garbage collections always occur before an out of memory error. And a few miscellaneous pages that suggested that ALL memory used by a Bitmap is deallocated upon GC (native and JVM heap alike)
I should note, at this point, that i'm testing on two different phones. Motorola Droid X (stock image, Android 2.3.3), and Samsung Galaxy S3 (Cyanogenmod 9, Android 4.0.4). Both exhibit the exact same behavior. My android tools are up to date with all SDK versions, and i've checked a million times to make sure that nothing else in my code is doing any weird allocations (practically nothing is allocated after program startup).
So, how should i properly deallocate a Bitmap so that it is freed (not just "unknown"), and i can use the memory elsewhere?
As a sort of supplemental question, what is this "unknown" memory pool, and what is it for?
EDIT: Grammar and spelling, added some notes on platform.
Use large image (also 1mb near). You may be use androidmanifest in application tag set large heap true.and than use custom View not use imageview (because too complex and need more than other views)
My activity has listview and (apart from all other stuff) loads images from web and displays them in listview. I have access to 5 android devices: 2 HTC desire, LG P-350, one more phone and a tablet. Normally, everything works fine, but being launched on one of HTC desire, app tends to crash with NullPointerException, which is due to out of memory error (I guess so), this is the output:
05-03 14:41:23.818: E/dalvikvm(843): Out of memory: Heap Size=7367KB, Allocated=4991KB, Bitmap Size=16979KB
Later, logcat outputs stack trace of nullpointerexception where one of my static variables suddenly becomes null (the variable is initialized in app's root activity, is used across the app and for sure is not nulled in code). I suppose, it is nulled by system due to lack of memory.
As far as I undesrstand, system tries to allocate bitmap as large as 17mb - I'm sure loaded images cant be that big. They are 100*70 jpegs and any of them weighs far less than 1mb.
Another thing I dont understand is why I get this error only on one device - other devices work fine.
To my mind, this looks very strange and I can find no clue, I need advice.
The reason is simple: the memory is not holding your JPG data per say, but rather its decompressed equivalent, which, needless to say, takes a lot more RAM space than the source files... Note that this 17 mb limit is for all your loaded bitmaps at once, not necessarily a single one.
I had to fight with similar problems in one of my programs (a custom Tile loader for a Mapquest Android API MapView object), and I ended up having to call the recycle() method of my bitmaps whenever possible, as well as manually oblige the system to garbage collect at strategic locations using System.gc()...
Sorry to not be the bearer of the best news...
You might solve your problems using the same strategy as I did: I essentially cache the loaded bitmaps in hard storage such as my external SD card, and reload them on the fly when needed, instead of attempting to hold everything in RAM.