Messages from Log.wtf() sound pretty bad

   One of the most annoying problem for third party developers and platform providers is inability to use the available feature sets of the platform for a rich user experience. This is the same problem that Steve jobs claimed to be the case for Adobe's Flash. Adobe was slow to update Flash to use the latest features of Mac OSX and wasn't really helping third party developers. Besides, flash being closed source too didn't help.     This was the case with Nvidia's shield platform too. Shield had Tegra 4 which supported OpenGL ES 3.0 APIs but wasn't really compliant to the standard. At launch, it was shipped with Android's Jelly Bean (4.2.1) which supported just Open GL ES 2.0 . In this case, Android graphics APIs had become the bottleneck on shield's hardware capabilities. Nvidia could have launched an SDK Add-on exposing new APIs to use ES 3.0 but took safe route hoping quick adoption of latest Open GL standards by Android and yes it worked out fine. Andr...

    Just ran into a need of a quick setup of database in Java and didn't want to spend time on File and String manipulation, fortunately came across Apache's Derby database and was able to get going within few hours and had enough time to get to other logic aspects. Started off using in-memory database and eventually moved onto a database hosted on a server without changing any of the application code.     This implementation is based on derby jars ( http://db.apache.org/derby/releases/release-10.10.1.1.cgi ), derby.jar is for in-memory database and derbyclient.jar is for hosting a database as a service. public class Database {     Connection mConnection;     String         mDbName;     boolean      mAutoCommit;     TYPE          mDatabaseType;         public enum TYPE {      ...

     Android's Messenger pattern is an abstraction on top of binder inter process communication to quickly implement a client-server interface. It can be used for both inter and intra process boundaries as the fundamental link is the binder driver.  Developers don't even have to deal with AIDL and instead just have to deal with an application level protocol between the interacting components and define messages. However, Messenger might not always fit the needs as,      All messages are routed through a single thread which creates the handler for the Messenger. Although, this has the advantage of thread safety, it could also mean potential delays, especially when multiple requests could be serviced simultaneously. Besides, there is also a delay for non simultaneous requests when using Messenger.    And, none of the requests from a client could be blocking unlike a AIDL interface api, which could either be one way or blocking. Server need...

    Android's low memory killer is based on application's out of memory score (oom_adj). The source of truth is in a file in proc filesystem (/proc/pid/oom_adj). Although, this is not really specific to Android, it is effectively used by Activity manager to help determine important applications. A foreground application being the most important application gets a score of 0. Higher the score, lesser is the importance and higher probability of being killed by low memory killer.   3rd party application developers might look for a way to cheat low memory killer and protect their app from being killed. However, this is not possible, not because the file /proc/pid/oom_adj can't be accessed or written into, instead is because of the sys call corresponding to a write request on the file.    An application code might look like this,         String fileName = "/proc/" + android.os.Process.myPid() + "/oom_adj";         File ...

      Android's shared user id (android:sharedUserId) is a way for different applications to share the same user id for permissions, which lets them access their data and host their components in other process space. By declaring a new sharedUserId in the manifest, a new user id is creating during installation and is ready to be used by other applications provided they are signed with the same certificate and one such use is to update android:process of an application component to host it in other process space.    However, if the applications don't share a user id and aren't signed with the same certificate, a new process is launched with the same name as in android:process and this new process automatically shares userId with the requested application.    If the applications share user id and and aren't signed by the same certificate, the installation of the apk would fail.     If the applications share user id and are signed by the ...

        Each package is given a unique user id during its installation and this remains the same as long as it stays installed in the device. The UID is generated by com.android.server.pm.Settings::newUserIdLPw(...) and is eventually saved in /data/system/packages.xml for persistent storage.     

Android's stopSevice's documentation suggests that the entire operation of stopping a service is synchronous and that the caller could use the result (boolean) to determine if the requested service was stopped or not. However, in my case, the requested service's onDestroy() wasn't invoked immediately, especially that it was hosted in its own process space. Turns out that the framework's callback to the requested service is actually one way   mRemote.transact(SCHEDULE_STOP_SERVICE_TRANSACTION, data, null,                           IBinder.FLAG_ONEWAY ); and the callback isn't handled immediately in the binder thread, instead if posted to the main thread which ends up invoking onDestroy() on the service.  And as far is the caller is concerned, a result is returned even before the requested service receives the callback. int stopServiceLocked(IApplicationThread caller, Intent service,     ...

      The most annoying memory usage for an android application is active references to finished activity and yet this is one of the most missed use cases and to make it worse the activity in turn could hold references to other application components and data structures effectively making it similar to its foreground version (in terms of memory usage). As a thumb rule, the dalvik heap after garbage collection shouldn't have any instances of the finished activity.       A simple test is to finish all application components like activity by pressing back key and initiate a garbage collection via DDMS and then look for leaks in the heap snapshot.

Android debug bridge being an application protocol can be run on top of different transport protocols. Most often used is over USB, however it can be run over WiFi. This could be used to quickly isolate random adb disconnect issues as the application layer protocol stays the same over all physical transports.    * Make sure developer options is turned on and the host machine is authenticated for adb usage.    * Connect the device via USB and request for the adb on the device to be restarted over TCP                   adb tcpip 5555    * Disconnect USB    * Find the IP address of the device via Settings > About Phone > Network                  * Connect to the device over TCP via                   adb connect ip_address :5555    * Disconnect from previously connected device. ...