Messages from Log.wtf() sound pretty bad

        One of the well received features was application's permission manager which was exposed indirectly and was later removed in a future update. I guess, this must have been done to ensure graceful handling of permission failures when used by applications. Few requests to vibrate etc could be ignored silently but requests like connecting to camera probably needs to be handled with a kind of notification to the user. And in the worst case, permission denial of this kind shouldn't trigger a framework failure. One such failure is when a pattern vibration request by an application is to be ignored ( https://android-review.googlesource.com/#/c/70914/ ), which ends up overloading the main thread of the framework process (system_server) and performance is noticeably impacted.

       One of the fascinating features of Android platform was the ability for 3rd party platform developers and OEMs to provide SDK Add-ons and the implementation too could have been closed source. Google used this to expose Google Maps API and as this approach had technical benefits like frequently used classes cloud be pre-loaded by Zygote, there by reducing application start up time, reducing memory footprint etc. This seemed fine and was based on the assumption that OEMs would be quick to upgrade platform images with new versions having potential bug fixes and new APIs for the SDK add-on and there promote the ecosystem serving application developers and end users.    Unfortunately, it wasn't necessarily in the best interest of the OEMs to do so and in some cases they wanted to promote an in-house developed API and services competing with Google. Google's approach to this was to distribute their API via Play store as an Play services apk and this wor...

Prerequisites    Built Android platform code base, SDK and NDK. Emulator setup /out/host/darwin-x86/bin/emulator -system   /out/target/product/generic/system.img -ramdisk out/target/product/generic/ramdisk.img adb shell setprop libc.debug.malloc 1 adb shell stop adb shell start        1  - perform leak detection        5  - fill allocated memory to detect overruns      10 - fill memory and add sentinels to detect overruns      20 - use special instrumented malloc/free routines for the emulator Host setup vi ~/.android/ddms.cfg add a line "native=true" export ANDROID_SYMBOLS= / out/target/product/generic/symbols export PATH=$PATH: /toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/ DDMS /tools/ddms Select the process in ddms and click on Native Heap tab and select "Snapshot Current Native Heap Usage".

     Ever came across an application taking too much time to launch, animate, stutter, download etc. Just came across this simple logging support by Looper to isolate the problem. Traceview does helps a lot when dealing with an unknown code base but with well known application code, the messages sent to the main thread often rings a bell. All that is needed is to find the message which consumes more cycles.   public void onCreate() {     Looper.getMainLooper().setMessageLogging(new Printer() {             @Override              public void println(String x) {                   Log.d(TAG, "Looped [" + x + "]");              }     });     ...     ...     ... }  Beware of the spam logs, if only there was an overloaded API to log only messages handled i...