If the process from a previous test still exists, so will its unclosed
file descriptors and the associated storage blocks.  Check ps in an
adb shell.

An interesting hack might be to register a file change notifier on
some part of yourself and finish() if it triggers... (indicating a new
version)

I've been noticing of late an annoying issue of eclipse managing to
resume the old version of a program rather than launch the new version
it just uploaded.  So as I'm mostly playing with native code
outputting to logcat I've been pushing the .so up by itself from my
Makefile and manually killing and home-long-press relaunching - need
to script that part too, or just go back to having the native on load
routine exit(;-)

On Sep 4, 11:04 pm, Jason <[email protected]> wrote:
> Hmmm.. yeah, makes sense.  I wonder if my app is somehow not releasing
> something.. somewhere.
>
> The only thing that I'm doing that may be "slightly" left of center is
> loading a native lib.  AFAIK there is no way to "unload" a native
> lib.  Can't see a reason why this would cause a file handle to be left
> hanging around though.
>
> On Sep 5, 9:13 am, Chris Stratton <[email protected]> wrote:
>
>
>
> > On linux, if you delete a file which soneone else has an open file
> > handle to, it doesn't actually go away until all handles are closed
> > (you just can't find it by name to open new ones).  I'm guessing that
> > when you install a new version during a development session the old
> > version isn't completely getting killed, and still has open handles to
> > its apk or odex. Or maybe something else running on your phone does.
> > When you use the task killer you kill of whatever is holding those
> > file handles so they get released and the old versions' "disk" space
> > becomes available for re-use.
>
> > I would wait until it gets "filled up" then launch the adb shell and
> > look around with ps and df commands.
>
> > On Sep 4, 4:47 pm, Jason <[email protected]> wrote:
>
> > > Hi all,
>
> > > This is more an annoyance than a real problem.. nevertheless:
>
> > > When testing my app on a device I go through several "installs",
> > > although it's really the Eclipse plugin doing this for me.  After a
> > > while (not very long) the device starts complaining about insufficient
> > > storage.  It seems that progressive "re-installs" eats away the phone
> > > storage even though the app being installed (presumably) is either
> > > removed by Eclipse first or at least overwritten.
>
> > > Interestingly if I use a task killer to kill everything on the phone
> > > (which I only use for dev purposes btw), the available storage
> > > indicator recovers and I can keep working.
>
> > > As I said, it's more annoying than anything as the workaround.. well..
> > > works, but I'm wondering if there is some sort of cache chewing up
> > > storage?  More importantly, I'm a little concerned that the same may
> > > happen with updates from the Market?  That is, the update effectively
> > > replacing the current version of the app but leaving an allocation of
> > > storage behind in its wake.
>
> > > Anyone else seen this, and have an insight as to whether this is just
> > > an eclipse/debug thing? (ie nothing to worry about).
>
> > > Thanks.

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to