Almost everyone developing an Android app has seen something like this in their logs.

On most devices, Android platform tries to render a new frame every 16 milliseconds (60 fps).   The rendering requires that whatever work is happening on the UI thread should finish in that timeframe (well, actually in less than that). Any unit of work (== Runnable) scheduled on the UI thread has to fit in that. When the work takes longer, then frames are skipped. 1 skipped frame is 16 ms of the hung screen.  the UI looks janky and unresponsive and if the user interacts with the screen and application does not respond in time (5 seconds) then Application Not Responding (ANR) shows up.

Another interesting scenario where the work can take longer is when the work involves acquiring a lock (for example, for executing synchronized code). Any synchronized code on the main thread is almost always a bad idea since you have no control over who could be holding the lock. And the developer writing the code to be run on a background thread has no idea that holding a particular lock can cause any problems. Android has two interesting tools to debug this. One of them is dumpsys for the statistical info, the other one is Method profiling via Android Device Monitor for identifying the culprits.

And, by the way, Choreographer is the class which does the actual rendering work.