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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment