[android-developers] Re: Memory leak or feature
Thanks for everybody for helping me with this. I checked the memory also with a memory profiler and I suspect that it is SearchManager that is keeping a reference to the Activity. And it seems that SearchManager is created for default for all the apps even though it is never directly invoked. Anyway, I think I will also file a bug report, because there is something strange happening whether it is in the dev tools or in the platform. But my sample app is so simple that I'm positive it is not leaking anything. As it doesn't in 1.1 OS. The size of your process doesn't make it more likely to be killed. Okey, this I didn't know. I though that when the OS decides to kill processes in order to reclaim memory it does it so that the larger processes are killed first. My mistake, should read the docs more carefully. (4) My meminfo results were slightly different than what Mika reported at the beginning of this thread. When the Activity is the foreground my process had 14 views, 4 AppContexts, 2 ViewRoots, and 2 Activities. After the Activity was destroyed it had 7 views, 3 AppContexts, 1 ViewRoots, and 1 Activities. So SOMETHING happened but I don't know how to interpret theses numbers - why would there be so many views, etc. for a simple 1 TextView application? I have these same results if I start the activity close it from back button and then start it again. Anyway, thanks for help everybody. Now it's time to go to fight MapActivity memory problems =) -Mika On Oct 22, 3:31 am, jotobjects jotobje...@gmail.com wrote: That may be. In this test the memory usage by Dalvik reported by meminfo never decreased even though the JVM Runtime memory usage did fall when the Activity was destroyed. The main point is that there is not a close correspondence between memory usage reported by Linux process stats and JVM free memory. So meminfo is not the best way to detect application memory leaks. On Oct 21, 4:27 pm, Mark Murphy mmur...@commonsware.com wrote: My understanding was that Dalvik VM returned memory to the OS, but I may be mistaken. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
I didn't notice meminfo shows 7 views the first time and 14 view the second time the Activity is started. So I do get that same results as Mika (shown at the top of this thread). But meminfo always shows 1 activity and at least 7 views and 1 activity even after the destroy (when theoretically there should be no activity or views). Thanks to Mark for the suggestion of using HierarchyViewer - The 7 views make sense including all the decoration and status bars, etc. HierarchyViewer still shows 7 views when meminfo shows 14. My conclusion - Without knowing where meminfo gets its statistics on views and activities there is no way to determine whether the activity is fully removed when it is destroyed. We do know that memory usage reported by meminfo has little correspondence with JVM free memory. So Mika's concern about the memory leak doesn't seem to be verifiable (true or false) with these tools. On Oct 22, 7:43 am, Mika mika.ristim...@tkk.fi wrote: Thanks for everybody for helping me with this. I checked the memory also with a memory profiler and I suspect that it is SearchManager that is keeping a reference to the Activity. And it seems that SearchManager is created for default for all the apps even though it is never directly invoked. Anyway, I think I will also file a bug report, because there is something strange happening whether it is in the dev tools or in the platform. But my sample app is so simple that I'm positive it is not leaking anything. As it doesn't in 1.1 OS. The size of your process doesn't make it more likely to be killed. Okey, this I didn't know. I though that when the OS decides to kill processes in order to reclaim memory it does it so that the larger processes are killed first. My mistake, should read the docs more carefully. (4) My meminfo results were slightly different than what Mika reported at the beginning of this thread. When the Activity is the foreground my process had 14 views, 4 AppContexts, 2 ViewRoots, and 2 Activities. After the Activity was destroyed it had 7 views, 3 AppContexts, 1 ViewRoots, and 1 Activities. So SOMETHING happened but I don't know how to interpret theses numbers - why would there be so many views, etc. for a simple 1 TextView application? I have these same results if I start the activity close it from back button and then start it again. Anyway, thanks for help everybody. Now it's time to go to fight MapActivity memory problems =) -Mika On Oct 22, 3:31 am, jotobjects jotobje...@gmail.com wrote: That may be. In this test the memory usage by Dalvik reported by meminfo never decreased even though the JVM Runtime memory usage did fall when the Activity was destroyed. The main point is that there is not a close correspondence between memory usage reported by Linux process stats and JVM free memory. So meminfo is not the best way to detect application memory leaks. On Oct 21, 4:27 pm, Mark Murphy mmur...@commonsware.com wrote: My understanding was that Dalvik VM returned memory to the OS, but I may be mistaken. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
Thanks for the replies. I checked that finish() is called for the activity when the user presses the back button. why do you expect the system to close the Activity and free the memory Well basically because if I want to do some background processing (playing music, tracking location etc.) while the user is doing other things I would want my process to use memory as little as possible so that the system wouldn't kill it. But if my UI i.e. Activities stay in the memory even when they are not used it makes the background process more likely to be killed. I also tried using some memory extensive apps (Maps, Browser, Camera) but the system still didn't free the activities of my app. if you are somehow measuring things incorrectly. That might be the case. So here is a brief explanation. 1. The sample app that I'm running can be found from: http://users.tkk.fi/~mristima/android/service_test.tar 2. I start the app 3. To check the memory consumption I run: adb shell dumpsys meminfo com.android.service_test. 4. I press the back button 5. From DDMS I force GC for system_process and my app process 6. Finally I run adb shell dumpsys meminfo com.android.service_test again. Is there something wrong or strange here?? Also what is interesting, is that using android 1.1 (AVD) as a target, all the activities are freed from memory but in 1.5 they are not. I'm really baffled about this, so it would be great to have some kind of explanation for this, or to understand what I'm doing wrong. -Mika On Oct 21, 1:10 am, Dianne Hackborn hack...@android.com wrote: I am pretty sure the standard music app doesn't leak, so I wonder if you are somehow measuring things incorrectly. On Fri, Oct 16, 2009 at 2:11 AM, Mika mika.ristim...@tkk.fi wrote: Hi Dianne, This is what I assumed also. Do you have any ideas where the leak could be in the sample app that I posted? I also checked the music player app with meminfo and it behaves similarly leaving activities in memory even after the ui is closed and system_process and com.android.music processes are GCed from DDMS. I also tested with 1.1 SDK and Emulator and there everything works as presumed and no activities stay in memory after they are closed. -Mika On Oct 15, 7:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.com wrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa. .. String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
I have adapted your sample and am experimenting with it... Further comments inline. On Oct 21, 3:43 am, Mika mika.ristim...@tkk.fi wrote: Thanks for the replies. I checked that finish() is called for the activity when the user presses the back button. That's interesting. I would not expect the system to kill an Activity just because it is no longer visible unless the device is in a very low memory situation already. This surprises me a lot. why do you expect the system to close the Activity and free the memory Well basically because if I want to do some background processing (playing music, tracking location etc.) while the user is doing other things I would want my process to use memory as little as possible so that the system wouldn't kill it. But if my UI i.e. Activities stay in the memory even when they are not used it makes the background process more likely to be killed. I also tried using some memory extensive apps (Maps, Browser, Camera) but the system still didn't free the activities of my app. This supposes that the system chooses processes to kill based on how much memory they are using - i.e., that processes using less memory are less likely to be killed. But that is not what the documentation says about the priority of processes hosting services - http://developer.android.com/reference/android/app/Service.html#ProcessLifecycle if you are somehow measuring things incorrectly. That might be the case. So here is a brief explanation. 1. The sample app that I'm running can be found from:http://users.tkk.fi/~mristima/android/service_test.tar 2. I start the app 3. To check the memory consumption I run: adb shell dumpsys meminfo com.android.service_test. 4. I press the back button 5. From DDMS I force GC for system_process and my app process You would have to do this AFTER finish() is called meaning the Activity has exited. 6. Finally I run adb shell dumpsys meminfo com.android.service_test again. Is there something wrong or strange here?? Also what is interesting, is that using android 1.1 (AVD) as a target, all the activities are freed from memory but in 1.5 they are not. I'm really baffled about this, so it would be great to have some kind of explanation for this, or to understand what I'm doing wrong. -Mika On Oct 21, 1:10 am, Dianne Hackborn hack...@android.com wrote: I am pretty sure the standard music app doesn't leak, so I wonder if you are somehow measuring things incorrectly. On Fri, Oct 16, 2009 at 2:11 AM, Mika mika.ristim...@tkk.fi wrote: Hi Dianne, This is what I assumed also. Do you have any ideas where the leak could be in the sample app that I posted? I also checked the music player app with meminfo and it behaves similarly leaving activities in memory even after the ui is closed and system_process and com.android.music processes are GCed from DDMS. I also tested with 1.1 SDK and Emulator and there everything works as presumed and no activities stay in memory after they are closed. -Mika On Oct 15, 7:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.com wrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa. .. String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message
[android-developers] Re: Memory leak or feature
On Wed, Oct 21, 2009 at 3:43 AM, Mika mika.ristim...@tkk.fi wrote: Well basically because if I want to do some background processing (playing music, tracking location etc.) while the user is doing other things I would want my process to use memory as little as possible so that the system wouldn't kill it. But if my UI i.e. Activities stay in the memory even when they are not used it makes the background process more likely to be killed. The size of your process doesn't make it more likely to be killed. And again, if your activity is actually being finished (by you calling finish() or the system doing that for you as a result of you pressing back in it), then all of the objects associated with the activity will be released. Unless you have leaked some references to it, such as in static variables. You can use the hat tool to look at the objects in your process, and follow the references to see why some aren't being garbage collected. Of course if you press home to leave the app, then the activity is still in use, and will remain around if or until the process is killed. If you want to reduce memory use while in this state, you can put code in onStop() to free up any heavy-weight resources (such as large bitmaps), and reload them on onStart() on onRestart(). I also tried using some memory extensive apps (Maps, Browser, Camera) but the system still didn't free the activities of my app. Using memory in other apps has -nothing- to do with freeing memory in your app. All it can result in is some not-needed processes being killed if the kernel is running low on available memory. Sorry, I don't have time to debug your app. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
Some observations after writing and testing a slightly modified version of the app shown at the beginning of this thread. (1) As Dianne points out the BACK key always destroys the Activity and the HOME key only stops the Activity (correcting my previous misstatement). (2) The Dev Tools app setting to immediately destroy activities apparently causes the Activity to be destroyed anytime it is not on top. But that doesn't add much to this test because you can use the BACK key to cause a destroy anyway. (3) Meminfo has very little to do with JVM memory use. For one thing the process has allocated memory for native code and well as for the JVM itself and for the actual application. Most JVM's do not return memory to the OS when their memory use declines -- the JVM just has more free memory available for future object allocations. In other words the JVM high water allocation mark does not recede. Android apparently just kills off the whole JVM and the process when it needs more memory (using a priority ranking for activities and processes that is documented). If you want to see what is happening with the JVM memory use, do something like this before and after garbage collection - Runtime rt = Runtime.getRuntime(); Log.d(Service memtest, --- Service Running - memory usage= +(rt.totalMemory()-rt.freeMemory())); In my case the memory usage drops by more than 100Kb after the Activity is destroyed and GC runs. So the app really is freeing up the resources when it is destroyed (this was Mika's concern). (4) My meminfo results were slightly different than what Mika reported at the beginning of this thread. When the Activity is the foreground my process had 14 views, 4 AppContexts, 2 ViewRoots, and 2 Activities. After the Activity was destroyed it had 7 views, 3 AppContexts, 1 ViewRoots, and 1 Activities. So SOMETHING happened but I don't know how to interpret theses numbers - why would there be so many views, etc. for a simple 1 TextView application? On Oct 21, 10:22 am, Dianne Hackborn hack...@android.com wrote: On Wed, Oct 21, 2009 at 3:43 AM, Mika mika.ristim...@tkk.fi wrote: Well basically because if I want to do some background processing (playing music, tracking location etc.) while the user is doing other things I would want my process to use memory as little as possible so that the system wouldn't kill it. But if my UI i.e. Activities stay in the memory even when they are not used it makes the background process more likely to be killed. The size of your process doesn't make it more likely to be killed. And again, if your activity is actually being finished (by you calling finish() or the system doing that for you as a result of you pressing back in it), then all of the objects associated with the activity will be released. Unless you have leaked some references to it, such as in static variables. You can use the hat tool to look at the objects in your process, and follow the references to see why some aren't being garbage collected. Of course if you press home to leave the app, then the activity is still in use, and will remain around if or until the process is killed. If you want to reduce memory use while in this state, you can put code in onStop() to free up any heavy-weight resources (such as large bitmaps), and reload them on onStart() on onRestart(). I also tried using some memory extensive apps (Maps, Browser, Camera) but the system still didn't free the activities of my app. Using memory in other apps has -nothing- to do with freeing memory in your app. All it can result in is some not-needed processes being killed if the kernel is running low on available memory. Sorry, I don't have time to debug your app. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
jotobjects wrote: Most JVM's do not return memory to the OS when their memory use declines -- the JVM just has more free memory available for future object allocations. In other words the JVM high water allocation mark does not recede. My understanding was that Dalvik VM returned memory to the OS, but I may be mistaken. (4) My meminfo results were slightly different than what Mika reported at the beginning of this thread. When the Activity is the foreground my process had 14 views, 4 AppContexts, 2 ViewRoots, and 2 Activities. After the Activity was destroyed it had 7 views, 3 AppContexts, 1 ViewRoots, and 1 Activities. So SOMETHING happened but I don't know how to interpret theses numbers - why would there be so many views, etc. for a simple 1 TextView application? Try running hierarchyviewer on your activity, and you will find your answer, at least for the # of views. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Training in Germany, 18-22 January 2010: http://bignerdranch.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
That may be. In this test the memory usage by Dalvik reported by meminfo never decreased even though the JVM Runtime memory usage did fall when the Activity was destroyed. The main point is that there is not a close correspondence between memory usage reported by Linux process stats and JVM free memory. So meminfo is not the best way to detect application memory leaks. On Oct 21, 4:27 pm, Mark Murphy mmur...@commonsware.com wrote: My understanding was that Dalvik VM returned memory to the OS, but I may be mistaken. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
So has anybody been able to test the sample app and found the leak. To me this seems a quite serious bug or I might have misunderstood some fundamental Android concept. But I doubt that it is desired behavior to leave Activities (or at least not its views) in memory when they are not used. -Mika On Oct 16, 12:11 pm, Mika mika.ristim...@tkk.fi wrote: Hi Dianne, This is what I assumed also. Do you have any ideas where the leak could be in the sample app that I posted? I also checked the music player app with meminfo and it behaves similarly leaving activities in memory even after the ui is closed and system_process and com.android.music processes are GCed from DDMS. I also tested with 1.1 SDK and Emulator and there everything works as presumed and no activities stay in memory after they are closed. -Mika On Oct 15, 7:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.comwrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa... String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
What happens if you override finish() to see if it gets called? What does Dianne mean by let the system finish the activity, i.e., what causes finish() to be called? On Oct 20, 1:48 am, Mika mika.ristim...@tkk.fi wrote: So has anybody been able to test the sample app and found the leak. To me this seems a quite serious bug or I might have misunderstood some fundamental Android concept. But I doubt that it is desired behavior to leave Activities (or at least not its views) in memory when they are not used. -Mika On Oct 16, 12:11 pm, Mika mika.ristim...@tkk.fi wrote: Hi Dianne, This is what I assumed also. Do you have any ideas where the leak could be in the sample app that I posted? I also checked the music player app with meminfo and it behaves similarly leaving activities in memory even after the ui is closed and system_process and com.android.music processes are GCed from DDMS. I also tested with 1.1 SDK and Emulator and there everything works as presumed and no activities stay in memory after they are closed. -Mika On Oct 15, 7:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.comwrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa... String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
Hi Mika - One more question - why do you expect the system to close the Activity and free the memory? Even though the Activity is not visible the system can keep it alive unless it needs to free memory. I think you would need to finish() the Activity yourself or fill up memory in the Service to see if the Activity is finally removed. On Oct 20, 11:39 am, jotobjects jotobje...@gmail.com wrote: What happens if you override finish() to see if it gets called? What does Dianne mean by let the system finish the activity, i.e., what causes finish() to be called? On Oct 20, 1:48 am, Mika mika.ristim...@tkk.fi wrote: So has anybody been able to test the sample app and found the leak. To me this seems a quite serious bug or I might have misunderstood some fundamental Android concept. But I doubt that it is desired behavior to leave Activities (or at least not its views) in memory when they are not used. -Mika On Oct 16, 12:11 pm, Mika mika.ristim...@tkk.fi wrote: Hi Dianne, This is what I assumed also. Do you have any ideas where the leak could be in the sample app that I posted? I also checked the music player app with meminfo and it behaves similarly leaving activities in memory even after the ui is closed and system_process and com.android.music processes are GCed from DDMS. I also tested with 1.1 SDK and Emulator and there everything works as presumed and no activities stay in memory after they are closed. -Mika On Oct 15, 7:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.comwrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa... String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
I am pretty sure the standard music app doesn't leak, so I wonder if you are somehow measuring things incorrectly. On Fri, Oct 16, 2009 at 2:11 AM, Mika mika.ristim...@tkk.fi wrote: Hi Dianne, This is what I assumed also. Do you have any ideas where the leak could be in the sample app that I posted? I also checked the music player app with meminfo and it behaves similarly leaving activities in memory even after the ui is closed and system_process and com.android.music processes are GCed from DDMS. I also tested with 1.1 SDK and Emulator and there everything works as presumed and no activities stay in memory after they are closed. -Mika On Oct 15, 7:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.com wrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa. .. String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
If you just need the activity cleaned up immediately for testing purposes then there is an app on the emulator called Dev Tools that might help. Run the app, choose the Development Settings option, then check the Immediately destroy activities option. On Oct 20, 4:23 pm, jotobjects jotobje...@gmail.com wrote: Hi Mika - One more question - why do you expect the system to close the Activity and free the memory? Even though the Activity is not visible the system can keep it alive unless it needs to free memory. I think you would need to finish() the Activity yourself or fill up memory in the Service to see if the Activity is finally removed. On Oct 20, 11:39 am, jotobjects jotobje...@gmail.com wrote: What happens if you override finish() to see if it gets called? What does Dianne mean by let the system finish the activity, i.e., what causes finish() to be called? On Oct 20, 1:48 am, Mika mika.ristim...@tkk.fi wrote: So has anybody been able to test the sample app and found the leak. To me this seems a quite serious bug or I might have misunderstood some fundamental Android concept. But I doubt that it is desired behavior to leave Activities (or at least not its views) in memory when they are not used. -Mika On Oct 16, 12:11 pm, Mika mika.ristim...@tkk.fi wrote: Hi Dianne, This is what I assumed also. Do you have any ideas where the leak could be in the sample app that I posted? I also checked the music player app with meminfo and it behaves similarly leaving activities in memory even after the ui is closed and system_process and com.android.music processes are GCed from DDMS. I also tested with 1.1 SDK and Emulator and there everything works as presumed and no activities stay in memory after they are closed. -Mika On Oct 15, 7:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.comwrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa... String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
Hi Dianne, This is what I assumed also. Do you have any ideas where the leak could be in the sample app that I posted? I also checked the music player app with meminfo and it behaves similarly leaving activities in memory even after the ui is closed and system_process and com.android.music processes are GCed from DDMS. I also tested with 1.1 SDK and Emulator and there everything works as presumed and no activities stay in memory after they are closed. -Mika On Oct 15, 7:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.comwrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa... String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/thread/fc97b4359f5c7880 String --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.comwrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/thread/fc97b4359f5c7880 String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
Is there a way to know the process has GCed? or to force a GC for this process? On Oct 15, 12:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.comwrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa... String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
java.lang.System.gc() On Oct 15, 11:22 am, RickGillaspy rickgilla...@gmail.com wrote: Is there a way to know the process has GCed? or to force a GC for this process? On Oct 15, 12:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.comwrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa... String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Memory leak or feature
You can also use DDMS to trigger a GC manually on any process you want. On Thu, Oct 15, 2009 at 12:04 PM, jotobjects jotobje...@gmail.com wrote: java.lang.System.gc() On Oct 15, 11:22 am, RickGillaspy rickgilla...@gmail.com wrote: Is there a way to know the process has GCed? or to force a GC for this process? On Oct 15, 12:56 pm, Dianne Hackborn hack...@android.com wrote: If you press back and let the system finish the activity, all references to it will be gone, so though your process is there after it GCs the resources (views etc) associated with the activity should be gone. If you still see them after you know the process has GCed, then you have a leak in your app. On Thu, Oct 15, 2009 at 7:57 AM, String sterling.ud...@googlemail.comwrote: On Oct 15, 3:08 pm, Mika mika.ristim...@tkk.fi wrote: So the problem is quite simple. I start a Service from an Activity, the user presses back, the Activity goes away and the Service stays running in the background. However the activity (and it's views) still stay in memory. Feature. It's central to the Android architecture that activities aren't killed by the system until their resources are needed elsewhere. The idea, I think, is that if the user goes back into your activity before that happens, it's ready and waiting. Some good discussion of it in this thread: http://groups.google.com/group/android-developers/browse_thread/threa... String -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
