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.
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
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.)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
19 matches
Mail list logo
