Android's hidden app permission manager

        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.

Deprecated Android SDK Add-ons

       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 works as OEMs are currently obligated to provide Play store as required by Android certification and the fact that end users wouldn't necessarily buy an Android device without play store. By doing so, google could continue to publish bug fixes and new APIs via Play store updates and end users get to take a call on the upgrade. This also places additional responsibility on 3rd party application developers to have a lot of run time checks for version, support etc. Technically, its a run time overhead but probably one of those cases where SDK Add-on developer's business interest gets more preference.

 OEM's response to this to try and promote their own App store and in some cases they have even announced 100% revenue for application developers and yet this is not going to be easy simply considering the reach and popularity of Play store.

  Meanwhile, what should 3rd party SDK developers be doing? Based on current trends, it looks like they are following Google's services approach and the in long run, the SDK Add-on might as well get deprecated.

   

Android Native Memory allocations and leaks

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".

Slow Android UI Thread

     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 in so much of time.