Re the ANR -- you just need to make sure you keep your main thread
responsive.  You don't know when the system may ask it to do something.  If
you get an ANR, just look at the stack traces to see what the main thread
was doing at that point, and fix whatever that is that is causing that.

If you are getting these reports in Android Feedback, you will find the
complete stack crawls there and should be able to determine fairly easily
what is happening.

If you are debugging on your own device or emulator, after an ANR happens
you can pull the stack crawls with "adb shell cat /data/anr/traces.txt"

On Sat, Dec 11, 2010 at 4:52 PM, metal mikey <[email protected]> wrote:

> > Also to the original poster -- Service.setForeground() will basically
> > guarantee that your process doesn't get killed for normal memory
> management.
> >  It will only be killed if it has crashed (either in Java, where you will
> > see the crash in the log, or in native code, which is harder to debug),
> has
> > extremely used a lot of memory to the point where nothing else can run,
> or
> > has had an ANR.
> >
> > > If this is happening, you should be able to see it in LogCat, and you
> might
> > > try moving your code into a background thread, as with an AsyncTask.
>
> I guess Zehon is failing for one of those reasons now under
> Gingerbread. I still can't be 100% sure whether my AppWidget was
> failing to download anything on GalaxyS for the same reason without
> debugging on an actual device (consistent killing of the Service at
> the point I see it killed in Gingerbread seems to be the best reason
> for GalaxyS users seeing data being used but never getting the full
> data update).
> Unfortunately LogCat only says something along the lines of:
>
>    Stuff happening as expected.
>    More stuff happening as expected.
>    com.me.project.allmyhardwork has died.
>    Scheduling restart of service com.me.project.allmyhardwork in
> 5000ms.
>    Restarted AppWidget as expected, lalala.
>    More stuff happening as expected.
>
> I.e. there is no ANR stacktrace nor any other stacktrace, the service
> just dies (gets killed). That probably corroborates the idea of Zehon
> failing silently and causing my Service to get killed too...
>
> I'm now using URLConnection (which utilises FtpURLConnection) to pull
> via FTP instead of Zehon for Java. Massive speed improvement, but
> while Zehon was able to establish FTP connection and pull data under
> emulator and most devices (at least the ones I can test on),
> FtpURLConnection always fails to establish a connection under
> emulator :( I guess that's to do with the proxy that emulator is setup
> to use...?
>
> So the new way using FtpURLConnection is working on real devices (the
> ones I can test on at least), now ANRs have reared their ugly heads
> and seem to be my next big problem. The data pull process is handled
> within an AsyncTask spawned by the Service, when it finishes, though,
> it quite often (especially on my NexusOne(2.2.1/FRG83D)) yeilds an
> ANR...that has me scratching my head because I don't broadcast to the
> Service at that stage, rather I have an Alarm that broadcasts to the
> service every 2 minutes to either Churn the display or Update the data
> (if update period has expired). Could it be that broadcasts to Churn
> during the Update process are getting queued (they shouldn't, they
> usually yield a Toast message indicating an update is underway) and
> the ANR is only able to make itself known once the Update AsyncTask
> has completed?
>
> --
> 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]<android-developers%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>



-- 
Dianne Hackborn
Android framework engineer
[email protected]

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