Develop Reference

Memory keeps rising without getting memory leak notification from leakcanary

I am new to android Profiler and still a noob at memory management. At first, I am having a notifications from LeakCanary so I fix them and successfully removed the leakage so the LeakCanary stops sending me notifications. But when I use the android Profiler I just noticed that the memory usage was rising bit by bit when I open a certain activity and then destroy it using finish(); method. Below are the sample screenshots of my Profiler when I open and close the OrdersActivity.
Here is the SS of total memory used before opening and closing the OrdersActivity
And here is the SS of total memory used after opening and closing the OrdersActivity
Also here is the stacktrace of the LeakCanary
I want to know if this occurrence of rising memory is normal? If not, is there a way to stop this? I am willing to show my codes If you need them in order to help me. I just didn't include it because it was too long.

LeakCanary will detect memory leaks, in the sense of objects that remain in memory when the activity is closed.
If you want to understand why memory usage is increasing as an activity is running, you can track allocations using the profile.
Edit: Also, it's hard to read a screenshot, but it seems to me that was is increasing when you start the activity is code (Code: Memory that your app uses for code and resources, such as dex bytecode, optimized or compiled dex code, .so libraries, and fonts.). In that case, that's perfectly normal: starting an activity need to load extra code (the activity itself, which is probably small, and all of required AppCompat if it hasn't been loaded yet). The usual strategy to test against memory leaks is to start and close the activity hundred times, and verify there is no memory increase between the 2nd time and the 100th time.

Simulate Out of Memory in android

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

android ndk - strange OutOfMemory error without memory leak

I'm working at a pdf reader app by using the native library from muPDF. Unfortunately I'm encountering an OOM error after a lot of swiping through the pages. I'm using the following code to get some insights in the memory behavior (I've also used the Android Device Monitor before):
Runtime.getRuntime().totalMemory() // amount of allocated memory in the app heap
Debug.getNativeHeapAllocatedSize() // amount of allocated memory in the native heap
Now comes the strange thing...due swiping through the pages the returned values of these to methods are always stable, so actually it doesn't look like there would be a memory leak at all. But after some time an OOM error occurs although the values of these two methods are still like at the beginning.
Does anyone know what is happening here?

You can try to prevent OutOfMemoryError from occurring by adding this in your application tag in your AppManifest.xml:
android:largeHeap="true"

Android clear the back stack if out of memory

When running on Huawei G300 with Gingerbread, my app crashes after 5 minutes or so of usage during setContentView() as it runs out of memory.
Each individual page doesn't use much memory, but from some research it seems the memory accumulates in the back stack.
Following advice here, I've replaced all my calls to startActivity with a utility function that also calls finish().
Android: Clear the back stack
This works; but there is no more back stack - the back button immediately quits the app, which isn't what I wanted.
Is there a way to only finish() the applications when I actually do run out of memory, and is that a reasonable approach to take?

You should search for memory leaks. A good tool for that is MAT if you use eclipse. MAT is not that hard to handle and you can get quickly some very valuable information.
One of the most common mistakes I have seen on Android is to keep a reference on a context that is dead. For instance, having a singleton holding a reference on one of the activities you created. There is no real reason for an app to crash the memory if it is well coded.

The Android Activity Manager was designed to manage this exact problem. The OS is designed to kill activities in the background and then restore them using onSaveInstanceState and onRestoreInstanceState.
The fact that your app is accumulating memory usage over time indicates to me that you may have a Context leak somewhere (a static reference to a view, adapter, etc. that has a reference to a Context), or that you have a caching mechanism that's not adjusting to your memory heap, or some other situation that's causing the out of memory.
I highly doubt that it's the Activities in the Back Stack causing the Out of Memory.
Here's a great guide on tracking down memory leaks on Android:
http://android-developers.blogspot.com/2011/03/memory-analysis-for-android.html

Memory is a very tricky subject in Android.
Every app gets a heap memory limit depending on the device. This heap memory is the dalvik memory plus the native memory, and you can see it as the total column in the dumpsys meminfo results. The dalvik memory deals with everything except with the bitmaps, that are allocated in the native memory (this is true for Android versions before Honeycomb).
Having said that I can only answer to some of your questions:
As far as I know, Android will always allocate memory for Bitmaps, even if they are the same. Therefore, in your case, every activity allocates memory for your background.
I don't know if its better to work with themes, you'll have to try that.
On one hand, activities are not reclaimed while the device has enough memory to deal with the next activity. Every activity is pushed to a pile from where it is recovered when you pressed the back button. In case Android needs more memory it removes one activity from the pile deallocating its memory (going back to question number one, maybe this is the reason for not sharing memory). On the other hand, you can set the activities launchMode to change this behaviour (have a look here).
I think MAT doesn't show native memory data. Use dumpsys meminfo's native column to see how much allocated memory for Bitmaps you have.
I have had hard times dealing with OutOfMemory problems myself. Now I have a much more clear idea of how it works and I am able to work with large files without running out of memory. I would highly recommend these two resources that helped me a lot:

Android Allocation Tracker understanding with Mapview

I am trying to optimize my app which is extensively using Mapview i.e. lots of ItemizedOverlay. While trying to see an app on allocation tracker after using an app for some time I am getting below view.
Few other information,
App is extending MapActivity. App is having fix orientation.
App is not opening any other activity (activity back and forth is not
happening).
Map is showing correctly on the activity.
I have seen multiple post on memory management, seen this Google IO video as well but could not address this problem.
App is running on ICS Tab.
My questions are,
Please see the Allocation in column and android_map_conflict.. value, does it suggest that it is the case of MapView + key conflict? What should be work around in such case?
Size of the memory allocation under android_map_conflict... is keep on increasing. any work around or higher level suggestion? I know it might not needed, but any forceful GC would work? At which place?

I'm not sure that I full understand the output of allocation tracker, but I believe it only refletcts the allocated memory, which can later be released and recovered by the GC. So, if you don't have a memory leak (a object that stills referencerd longer then needed) the allocated memory will be returned to free memory.
If you are experiencing issues with memory leak, they may be coming from somewhere else as well. I suggest that you install the MAT as shown in the video you refer. I've done so, using the version Eclipse plug-in, and it worked like a charm. I found the leak in a couple of minutes (after spending a couple of hours, trying to understand how MAT should be used :-) )
good luck