My solution was to take away the problem. Reworked things so I could simply pull data over HTTP. No more headaches! A shame though, as I'd put a lot of time into getting FTP working on most phones under most versions of Android...but the different behaviours I was seeing across makes/versions was disheartening and the cause of those headaches.
On Dec 12, 12:28 pm, Dianne Hackborn <[email protected]> wrote: > 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
