Any special Android deadlock debugging tricks?
<p>I’ve been working on building a nice graphical selector for an Android project. Unfortunately, this selector is causing me lots of frustration due to a deadlock in the application’s UI thread.  Parsing and rendering the various SVG layers that make up each clock is a relatively expensive operation. Locking up the user interface while doing these operations is clearly bad design, so I'm trying hard to give good feedback.</p>

<p>The selector consists of two columns, an image of the clock on the left and the name of the clock on the right. Using the standard ListActivity support, the goal is to show an indeterminate progress image in the left column until the clock layers have been loaded and rendered. At that point, the animated progress image is hidden and the clock image is displayed.</p>

<p>The implementation is simple in concept. The list adapter subclasses the standard BaseAdapter implementation to provide an implementation of the getView method. The getView method delegates loading of the clock’s image to an asynchronous executor service, keeping the user interface alive. When the asynchronous task completes, it posts a runnable to the UI thread to hide the progress indicator and show the image view.  There is logic related to properly handling recycled item views as well.</p>

<p>While this is mostly working, I’m hitting a random deadlock condition that locks up the UI thread, usually resulting in an “Application Not Responding” (ANR) error message to the user. All of my attempts to diagnose and resolve this issue have ended with nothing but frustration. So far, I’ve tried all of the “standard” approaches to diagnose this:</p>

<ul>
<li>Analyzed the traces.txt file generated by the ANR.<br>
Unfortunately, the process never shows up in the log file. 
Force-generated a traces.txt file using kill SIGQUIT pid while the application was still running.  Again, the process doesn’t seem to show up. Instead, I see “W/dalvikvm(19144): threadid=4: spin on suspend #1 threadid=9 (pcf=0)” whenever attempting this. </li>
<li>Enabled kernel-level deadlock prediction, but it never showed anything </li>
<li>Attempted to use the standard Eclipse debugger to suspend the UI thread once it is locked up.
No big surprise that it did not work. Added lots of Log output trying to pinpoint the hang.  At least from that logging, it doesn’t appear to be a hang anywhere directly in my code. </li>
<li>I even tried to use method tracing to see if I could figure anything out.</li>
</ul>

<p>At this point, I’ve run out of good ideas on how to track down and fix this problem on my own. I've removed all synchronization in my code and I'm still hanging up, implying some kind of hang in the underlying platform code.  Without a stack trace, I'm truly flying blind at this point.  Can anyone offer any ideas?</p>
