Messages from Log.wtf() sound pretty bad

The closest alternative to find the active components in a process.                 adb shell dumpsys activity p package_name This is not specific to the process but at the level of a package. In case of Google Play services, components of the same package is hosted in multiple process.   *APP* UID 10007 ProcessRecord{b20c2d08 518: com.google.process.location /u0a7}     user #0 uid=10007     class=com.google.android.gms.common.app.GmsApplication     manageSpaceActivityName=com.google.android.gms.app.settings.ManageSpaceActivity     dir=/system/priv-app/PrebuiltGmsCore.apk publicDir=/system/priv-app/PrebuiltGmsCore.apk data=/data/data/com.google.android.gms     packageList={ com.google.android.gms }     compat={320dpi}     thread=android.app.ApplicationThreadProxy@b202e408     pid=518 starting=false     ...     ......

One of the advantage of Google play services was being deployable via Play store and there by updates to the same ins't bottlenecked by device manufacture's software update cycle. However, this wasn't the case with emulator and as per the developer documentation at, an additional step of installing the Google API add-on is required. However, its not clearly documented as to why this is needed and why just for an emulator, especially that it kind of suggests a system image dependency.     Launching a sample application using Play services API on emulator with and without the Add-on throws some light. Application is able to connect to the play service on the emulator with the Add-on but not on the other one.    Upon closer look, the emulator with the Add-on actually hosts the play services process (com.google.android.gms) and that makes better sense. An alternative distribution of Play services apk without access to the Play Store.      ...

     Early versions of Android supported sending a signal to the process to generate its heap dump, which was changed and isn't available anymore. However, there is another hook via activity manager to generate the heap snapshot                adb shell am dumpheap pid file                adb pull file

  I have been used to control application debug options via adb shell or recompilation with debug turned on etc. Although this works fine, in some cases its not convenient, especially when testers work on the applications.    So found this nice little trick that lets anyone enable and disable debug options. It doesn't need the app to be recompiled or access to adb. Users would just need to increase or decrease the volume to control the debug options.    DebugActivity extends Activity {           public boolean dispatchKeyEvent (KeyEvent event) {                  final int keyCode = event.getKeyCode();                  if (keyCode == KeyEvent.KEYCODE_VOLUME_UP) {                       // Enable Debug options                  } else if...

       I had to fetch the java stack trace from native code which happened to throw an exception upon a failure. Unfortunately, this particular native function had multiple entry points from Java and a tombstone only helped find the native stack trace and not the java stack trace. All that was needed, was to send SIGNAL_QUIT to the current process and that was already being handled by dalvik virtual machine hosting the application. The threads are suspended and the java stack trace is saved in /data/anr/traces.txt                     kill(getpid(), 3);

Found this nice global API to fetch the process name in native code.                       include "cutils/process_name.h"                      /** Gets the current process name. */                      const char* get_process_name(void);