using TraceView

by rajorshi » Fri, 23 Apr 2010 17:07:38 GMT

Sponsored Links

 Hi,
I have recently started working on an app which has both Java and
native components. I am trying to generate trace information for both
components using Debug.startMethodTracing("myapp") and
Debug.startNativeTracing() alternately. However, both are behaving
unexpectedly. When I use Debug.startMethodTracing("myapp"), I can see
a file "/sdcard/myapp.trace" being created but it is always empty no
matter how long I run my app. When I use Debug.startNativeTracing()
and start the emulator with the -trace <tracename> switch, I see a
message saying "Trace started", but when I try to run my app, the
emulator crashes. Am I missing something obvious here? How do I debug
this problem?

Thanks for any help.

--

Top

Hi, I ran into a problem that doesn't know it should be classified as a bug. I am using Android 1.6. When I make a post: POST /OBN/OBNServlet HTTP/1.1 user-agent: Java0 connection: Keep-Alive content-type: application/x-www-form-urlencoded accept-encoding: gzip host: xxx (intentionally removed it) content-length: 0 I got this response: HTTP/1.1 200 OK Date: Mon, 01 Mar 2010 03:48:24 GMT Content-Encoding: gzip Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/plain ... (chunked binary data) If I wrapped the return InputStream by GZIPInputStream and start reading it: InputStream is = new GZIPInputStream(conn.getInputStream()) I will encounter a problem reading response from the next post. The reason is GZIPInputStream will not read the end of chunked encoding (in hex: 30 0a 0d 0a). After digging into the source code i found the place that it ignores the last chunked: InflaterInputStream.java (line 190 to 192) if (inf.needsInput()) { fill(); } Because there is left the end of chunked encoding and the connection is set to keep-alive, the next post response received (30 0a 0d 0a) as the header and the rest of the response data as body. What I have to do to get around the situation is to reference to the original input stream and read until -1 is reach before closing (note: if I use GZIPInputStream it will not work because GZIPInputStream all ready think it doesn't need anymore data). This is very confusing for developers because GZIPInputStream doesn't behave as expected as InputStream when you get -1 from read() method. Can we classified this a bug in GZIPInputStream? Thanks, SN --

I'm looking for a way of making TextToSpeech.synthesizeToFile save output to internal memoryl instead of /sdcard. I've read the docs: http://developer.android.com/intl/fr/resources/articles/tts.html, then had a quick look at the SDK source code. Found out that SDK TTS functions are using the PICO Text to Speech from libttsespeak.so, didn't go any further yet. Anyone ever synthesized a text to a File and did it to internal memory, (like a FileOutputStream), not to /sdcard? I want to be able to publish the saved wav through a Content Provider. And being dependent on the presence of /sdcard does not seem the ''proper'' way to me. Or am I wrong? --

android-discuss, using TraceView

using TraceView