Traceview: trace file not found

by Graham Morehead » Mon, 03 Nov 2008 05:39:34 GMT

Sponsored Links
 In an attempt to debug my app, I was trying to use 'traceview' (one of
the apps in the the android SDK).  In the windows edition of the SDK
version 1.0, the executable is 'traceview.bat'.  I was able to get a
tracefile by using the 'android.os.Debug' package and using
Debug.startMethodTracing("basename"); and Debug.stopMethodTracing();
in my code.  I created a virtual sdcard for the emulator to use, and
then I ran the app on the emulator and was successful in creating a
trace file, which I pulled to a directory.  Here was my problem:
Whenever I tried to view the trace using 'traceview.bat', it said that
the file is not found.  This was hard to understand since I specified
the right directory.  I even went into that directory.  It still
couldn't find it.  I finally resolved it when I specified the whole
path using the notation  "C:/topdir/nextdir/... etc."  If you're not
familiar with Cygwin (a Unix shell for windows), you also have the
choice of specifying a path with "/cygdrive/c/topdir/...", but
'traceview' won't parse that.

Hope this helps someone.  It stalled me for hours.


Other Threads

1. Bug detected VideoView/ImageView

I think that I found a problem with Android SDK
in a relative form, try to add An ImageView and A VideoView
In an activity, retrieve your VideoView and try to retrieve his
SurfaceHolder....Your application have to crash with a real big
tracelog in LogCat....

2. Widget process lifetime: Why not stop the service?

I'm writing a widget that needs to update rather infrequently (say
multiple hours). Following the source examples out there, it seems the
common solution is to use a service to prepare the updates. However,
after I am done, my process is still running on "service level", it
looks like it's not being killed by Android in low memory conditions,
and killing it manually causes it to restart.

The same seems to be true for all other widgets I have installed so
far - they stay in memory.

Wouldn't it be better to have to service call this.stop() when it is
done, at least if the widget knows it probably won't need to do
another update any time soon?

I'm doing this now, and it seem to work fine - my process is being
killed when Android needs memory. I'm confused though as to why this
wouldn't be the encouraged behaviour then (it's not like the G1 has an
aweful lot of memory to spare). Should or shouldn't I be doing this?

3. Main and three binder threads are running after application close

4. How to cancle a dialog when touch it?

5. Intent Selected_alternative

6. Docs: AsyncTask

7. AsyncTask posting mulitple parameters