Messages from Log.wtf() sound pretty bad

    Android's watchdog implementation stayed same through out most versions of Android until Kitkat. It had to be modified to support variable timeouts rather than the standard 1 minute timeout interval. Based on a commit e6f81cf1f69e0683f969238f921950befba8e6c3, this was done to support lengthy operations like application installations of multi giga bytes in size. Yet, this still supports the previous one minute based checks too. This is implemented by having the Watchdog thread post runnables to different threads (having a looper) associated with them. In the current implementation, these runnables are posted to Foreground Thread (android.fg), Ui Thread (android.ui),  Io Thread (android.io) and MainThread, Window Manager, Activity Manager, Package Manager, Power Manager.     The runnable (HandlerChecker) is a generic implementation and is not specific to the type of the thread to which it it being posted (Io, Fg etc). It checks the status of requested Moni...

      The default implementation of Android's Watchdog is going to restart Android Framework if its in an unrecoverable state and this makes sense for end users by offering graceful handling of the failure scenario. However, this could be a challenge for platform developers to root cause. I happened to come across a scenario where the UI would freeze and eventually watchdog would restart the framework. Watchdog does generate minimum debug info like stack trace of system_server, mediaserver, SurfaceFlinger etc. However, this isn't necessarily helpful in all cases and in this case, Window Manager was blocked on a call to create a new surface and this call was serviced by SurfaceFlinger, which was waiting for a composition response from the hardware composer and further logic was really specific to this particular vendor's HAL implementation. Unfortunately, Android's watchdog isn't generic enough to generate vendor specific debug information and hence the challenge wa...