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 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 -~----------~----~----~----~------~----~------~--~---
