Messages from Log.wtf() sound pretty bad

     Android's low memory killer was introduced to proactively look for low memory situations and kill least important or background process to restore some memory. So much so that one of the google developer at Google IO 2011 claimed that malloc in Android would never fail. For most part this makes sense and an android device with many applications would usually have low memory kill logs in dmesg. [  793.376328] select 378 (Usage), adj 10, size 5552, to kill [  793.376354] send sigkill to 378 (Usage), adj 10, size 5552 [  794.313554] select 409 (Homescreen), adj 8, size 4065, to kill [  794.313576] select 500 ((Preallocated a), adj 10, size 2787, to kill [  794.313591] send sigkill to 500 ((Preallocated a), adj 10, size 2787 [  796.038379] select 409 (Homescreen), adj 8, size 4213, to kill [  796.038398] send sigkill to 409 (Homescreen), adj 8, size 4213       However, in some cases, the kernel logs might have...

     Applications distributed via system image are usually updated with a new firmware update but this is more often than not an overhead for the application developers as their update is bottlenecked by device OEM's firmware update schedule and for OEMs who have to factor in extra cycles just to work with independent developers.  This was the case with Dolby's services available in Kindle devices . The service was in-built into the system image and applications had to use a thin client jar to talk to the service similar to Google's Play services. The only problem was that any bug fix in the service had to come through a firmware update from Amazon unlike Play services (updated via Play store).    So why would anyone go this route? Why not let the users install the applications from the market? Well, this is a good revenue source for mobile carriers and device OEMs as they promise instant visibility of the application to independent developers. Like...