> 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]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
