Messages from Log.wtf() sound pretty bad

     Ever wanted to look at the view hierarchy of closed source 3rd party apps? Welcome Cyanogenmod with google apps package to get google play store.  I wanted to check the view hierarchy of Google Plus's Auto Hideable ToolBar and with little effort got a CM build on a Nexus 4 and managed to find the ComposeBarView.

      I was curious about the implementation of Facebook's chat heads launched few weeks back as a part of Facebook Home. Wondered if chat head was an overlay or being written directly to the surface but it didn't make sense for the framework to grant such control to an app and Facebook's home and chat head was being distributed as just yet another app from App store. So how does it work. Turns out that Chat head uses a public API, SYSTEM_ALERT_WINDOW  and App store lets users know about this permission and that the app might display content on top of other applications.     In android UI, all controls need a context to be created and Chat Head is no exception and is created by Facebook messenger application (com.facebook.orca). Killing Facebook messenger application clears active Chat Heads as the context isn't valid anymore. Based on the ownership of chat heads, it is indeed vulnerable to low memory killer, even t...

    Dropbox had recently announced a SDK for android to facilitate app developers to use its cloud functionality. Facebook too had a similar SDK . Considering the existing database and reach of facebook, it only makes sense for application developers to use facebook SDK to share relevant information like scores in a game etc. Users might end up using multiple applications built on top of same 3rd Party SDK, but what exactly is the memory implication in the device?     The SDKs, especially when it doesn't involve any native libraries, gets linked into respective application process, each having their own version of the jar. In case of Android, once the process gets started it doesn't get killed until low memory killer kicks in. Any attempt by the user to launch a new application using the same SDK doesn't leverage the already loaded code segment of the SDK and with more application launches, the memory overhead just increases. Application built just...

        The default inflater of android for inflating views from layout resource expects both layout_width and layout_height attribute to be specified in the layout manifest. Any attempt to skip these attributes for custom views (having layout params in code) causes a run time exception, "You must supply a layout_width attribute" and with the current version (Jellybean) of layout inflater, custom views will have to override the layout parameters (specified in the layout xml). There are different solutions like updating the layout parameters in View's onMeasure, the only downside being that the onMesaure is invoked more often that what is needed for this purpose. The alternative is to override, setLayoutParams, which is invoked once by the layout inflater.    @override    public void setLayoutParams(LayoutParams params) {       params.height = ...;       params.width  = ...;   ...

        Android open source project (ICS) supports a maximum of 15 hidden applications running at any point and any attempt to launch new apps kills the least recently used ones. As per the documentation, this is done to reduce the load on RAM and has been the case since early version of Android.        However, the OEMs who port android on their board often don't realize that this number is a based on the size of RAM on the device and i just came across one such device whose activity manager started knocking out processes as soon as the device booted up (without any user intervention to start an application). It was obvious that they wanted more applications to be launched simultaneously, however didn't care about the maximum limit. 02-19 13:43:55.194 I/ActivityManager( 1096): No longer want com.lge.omadmclient:remote (pid 23052): hidden #16       And as to what the factor is... Its probably based on the m...

      Android framework supports boot up notification (broadcasts) for applications to start after the device boots up or after the framework reboots. Framework has to start a new process to host the Broadcast Receiver component and this takes more processing time compared to an already existing process. The only alternative is to have the empty process created even before processing broadcast boot up event and this is a small time window in the context of device boot up and yet android supports this for applications installed as a part of the system image.     All that is needed is to enable the application to be persistent in its manifest (android:persistent="true"). Activity Manager has the logic to create empty process (via zygote) for all persistent applications.    The only downside being that this is supported only for system applications controlled by platform developers and support for 3rd party apps would need an and...

     Java's JVM specifications ( http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf ) claims that writes to and reads of references is atomic on both 32 bit and 64 bit implementation and i happened to have a code which enforced mutual exclusion on the destination variable, public void set(Test ref) {   synchronized (this)   {      // obj is the member variable      obj = ref;   } }    At some point the need for synchronization was in question, as write into a reference is atomic and i started looking at underlying assembly instructions for the above code without synchronized block. I used 64 bit implementation of Open JDK 7 Update 3 on Ubuntu running on Intel x86 64 bit processor. The assembly code turned out as, Decoding compiled method 0x00007f8c5d061110: Code: [Entry Point] [Constants] # {method} 'set' '(LTest;)V' in 'Test' # this: rsi:rsi = 'Test' # parm0: rdx:rdx = 'Test' ...