Messages from Log.wtf() sound pretty bad

   Android's callback APIs are well sequenced and works as expected for most of the time. However, i ran into this problem where in a ListView's onItemClick() was invoked after the fragment's view was destroyed. Some search suggested that this could be because of the delay in processing Fragment Transactions, especially as they are posted to the main thread and executed in the next available slot and not immediately.      But after spending some time in Fragment transaction, it turns out that this was an issue with frameworks's AbsListView. Besides, this was seen only with a ListView in a Fragment and not with other AdapterViews or custom views. As and when the Fragment is being destroyed, all the views attached to the activity window has to be detached. AbsListView has a custom logic when it is detached from the parent window,     @Override     protected void onDetachedFromWindow() {         super.onDetachedFromWin...

   Android's LoaderManager APIs can be used to hook up the new instance of the Activity ( after an orientation change) with the existing Loader (started by the old activity instance before the orientation change). The internal implementation is described here and it works fine except for one use case. It works fine because Android framework is able to detect the orientation change and invokes a specific API to save info in the old activity instance. However, there is one use where things aren't saved,   * User launches the activity and triggers the background operation to launch the Loaders   * User pushes the application to background via Home key   * User changes the orientation in Launcher activity   * User resumes the app from the recent app list     Now, as the application is resumed, Android has to destroy the old instance and recreate a new instance to handle the new orientation. However, as and when this happens, getSupportLoad...

     Android's service life cycle seems straight forward and for cases when a Service is started explicitly, developers expect callbacks onCreate() followed by onStartCommand() and eventually a onDestroy() callback as the service is stopped. However, android's service life cycle documentation has the following, Services can use their stopSelf(int) method to ensure the service is not stopped until started intents have been processed     This seems to suggest that its possible for the service to be destroyed even before the intents are processed, i.e, for onStartCommand() to be invoked. So how often can this happen and what influences this behavior? The worst case scenario is obviously for a client to start and stop service immediately in the same thread.     private void startStopService()  {         Intent intent = new Intent(this, MyService.class);         startService( intent );     ...

   Address Sanitizer's support for Android works quite well that the application isn't slowed down to a drastic extent that it isn't usable anymore. The latest NDK ( Revision 10d ) offers easy use to enable address sanitizer for applications. It doesn't work in Android L and isn't supported for 64bit ABIs.    It needs the following compile time options to be enabled in Android.mk,          LOCAL_CFLAGS    := -fsanitize=address -fno-omit-frame-pointer          LOCAL_LDFLAGS   := -fsanitize=address          LOCAL_ARM_MODE := arm and following in Application.mk to use clang 3.5          NDK_TOOLCHAIN_VERSION=clang3.5    Address Sanitizer basically instruments the code for run time analysis and doesn't offer static analysis. This works for malloc, realloc and free. new and delete is supported only when c++ stdlib is linked dynamically...

    Android framework supports applications or different product flavors of the same application (like free and pro) to use the same library dependencies. The library could expose components like Activities, Services, UI widgets etc. These java based libraries are linked into these multiple applications and are not shared unlike native libraries which are loaded once into memory and shared across processes.     A typical application with product flavors might be setup to change the package name during the compilation process,  android {     ...     productFlavors {         pro {             applicationId = "com.sample.testapp.pro"         }         free {             applicationId = "com.sample.testapp.free"         }     }  }  dependencies {     ...  ...

   Android's Dialog APIs typical usage picks up the theme of the context (Activity) that is used to build the Dialog.             AlertDialog.Builder alertDialogBuilder = new AlertDialog.Builder(MainActivity.this);     The dialog is now going to be based on the Activity's Theme. However, there are cases when the Dialog needs to based on a different theme and AlertDialog has an overloaded Builder API to specify this custom theme.              public AlertDialog.Builder (Context context, int theme)    Note that the theme attribute isn't an explicit style (DialogTheme) instead is a reference attribute in the current theme that points to Dialog theme.     <style name="AppTheme" parent="android:Theme.Holo.Light.DarkActionBar">         <item name="android:alertDialogTheme">@style/DialogTheme</item>     </style>   ...

    Android comes with a basic firewall support and it is exposed via Setting's Data Usage. The setting is meant to fine tune network access settings, enable/disable background data in Mobile networks, enable/disable data roaming. Network access by background process (background data) can be controlled either for the entire device or per application basis. So how is this achieved and how can this be used for other purposes?      Android's NetworkPolicyManager is the entry point for Settings app. Settings app being an system application has the permissions to request changes. Besides, NetworkPolicyManager is hidden from the SDK too. Settings app uses APIs like setRestrictBackground, setUidPolicy. In Android world each and every application has its own uid and this is picked up by settings and passed on to the framework via setUidPolicy. From here on, NetworkPolicyManager routes the request to Framework's network policy manager service, which routes the re...