Messages from Log.wtf() sound pretty bad

Came across this piece of code in android's service_manaer.c and the heap allocation of the instance is interesting. struct svcinfo { struct svcinfo *next; void *ptr; struct binder_death death; unsigned len; uint16_t name[0]; }; An instance of this struct is dynamically created, struct svcinfo * si = malloc(sizeof(*si) + (len + 1) * sizeof(uint16_t)); This could have also been done by just allocating the memory for the pointer like name_ptr and having that point to another section of heap memory (holding the name). But the above approach has some advantages, first that memory for the pointer isn't needed explicitly and that the entire object would be allocated in a virtually contiguous memory and a higher possibility for the entire object to be present in a same page. This could have also been done by just allocating the memory for the pointer like name_ptr and having that point to another section of heap memory (holding the name). But the above approach has some ...

Following is applicable only for pre-kitkat version. For Kitkat and above, refer to updated version . Android framework's watchdog is meant to deal with cases when any of the following locks is held for more than a minute or when ServerThread is busy. ActivityManagerService.this PowerManagerService.mLocks WindowManagerService.mWindowMap WindowManagerService.mKeyguardTokenWatcher WindowManagerService.mKeyWaiter Watchdog thread posts a message MONITOR to android.server.ServerThread. It end up in the queue of message handler, HeartbeatHandler. The definition of HearbeatHadler is defined in Watchdog.java but its instance is actually created by ServerThread. android.server.ServerThread's looper thread would read all pending messages including w atchdog's MONITOR message and would invoke an appropriate handler. The handler of MONITOR message would simply check for availability of above mentioned locks. It doesn't involve any inter thread communication (between...