Maps don't (didn't -- this is 4.0.2) need any panning to cause a reboot: http://www.youtube.com/watch?v=mC4EegjeWZA
-- K 2012/12/29 lbendlin <[email protected]> > I can second the map panning effect. That seems to be able to lock up some > older devices (with less RAM, or poorly managed RAM?) randomly. > > On Friday, December 28, 2012 7:34:05 PM UTC-5, Nathan wrote: > >> This is a topic that is on my mind once in a while. >> >> What could an app do that would cause a hard freeze on an Android device? >> Obviously something really bad. >> BY a hard freeze, I mean one where the user claims to have to change the >> battery or use an advanced keystroke to restart the device. >> >> Theoretically nothing, right? After four seconds of not responding, the >> Force Close dialog should appear, letting them close the program and report >> through the market. >> >> But in the real world, I do believe it happens. I get a few reports of it >> every month or so. Fortunately, not often, but I would like to keep it so. >> My app doesn't use any native or OpenGL calls. Most recently, a user says >> he can get a consistent freeze by panning the view. >> Panning a view is a simple operation for the user, (though it is rather >> complicated in my custom view code), but there are 4000 other users doing >> it on the same device without complaint. >> >> I have very little to go on in these reports. After a full reboot, there >> is little chance the logcat still has useful information. Since 4.1, we >> can't use any external programs to collect the log. I aim for prevention >> instead. >> >> Anyway, please just post your best theories. >> >> Here are a few things I suspect might cause these things: >> Firmware/hardware errors in the device: >> Some users complain about random freezes and reboots on particular >> devices that seem independent. >> It is certainly possible that an app developer could just be hitting a >> path that freezes the device. >> Example: HTC Droid Incredible, June 2010. The phone would spontaneously >> report if you updated an ongoing notification more than a few hundred >> times. Never found out why. To this day, I only update progress when it >> moves a full percentage point. >> >> Runs out of memory: >> Getting repeated outofmemory errors on background threads may not cause a >> crash, but I think that eventually the main thread would get some errors >> too. I think the Force Close should happen then too. >> >> Event loop gets full: >> If, for example, onDraw takes .2 seconds but is called every .1 seconds, >> you will eventually get behind and the user input would not be processed >> and the system would appear frozen to an average observer. The same could >> happen if a Handler message queue got really full. I would expect this to >> cause a Force Close, but you never know. Maybe the CPU overloads too fast. >> >> Device or storage overheats: >> I have found where the device gets physically hot, they have been >> manifested as SQLiteIOExceptions, indicating the file doesn't exist when it >> does. >> >> Case in point: >> I have done a stress test where I have done the following: >> GPS Locationlistener on service at 1 second intervals. >> Do some computation in the listener >> Insert or update up to 800 bytes of data to an SQLiteDatabase on storage >> in this listener. >> (The above two items in main thread). >> >> I did this driving at 45 mph with a Droid 1. >> Did great for a while. >> After an hour I observed behavior where it appeared unresponsive. No >> Force Close dialog. Phone was measurably warmer than normal. I could even >> see it happening in degrees, where it might take two seconds to respond to >> a touch, then ten seconds, then a minute or two. If the above stress was >> removed, it might eventually get back to normal where it was caught up. But >> an average user would of course think it completely frozen and pull the >> battery. I suspect the "full event loop" from above, possibly causing or >> being caused by IO errors. >> >> Anyway, your thoughts are welcome. >> Any sure fire technique you have found for freezing an Android, let me >> know and I will try to *not* do it. >> >> Nathan >> >> > -- > 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 > -- 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
