A Complete build.gradle for the Experimental Android Gradle Plugin

Along with the latest release of Android Studio 1.3 rc3, the experimental gradle plugin supports NDK integration in a seamless way. However, the official quick guide does not show every essential detail to write a working build.gradle. The tricks to pay attention to is as follows.

• compileOptions inclduing the sourceCompatibility and targetCompatibility testInstrumentationRunner 
• packagingOptions multiple cppFlags and ldLibs 
• specifying of debug ndk abiFilters 
• dynamic generation of android.productFlavors 
• dependencies of 'com.android.support.test:runner:0.3' and 'com.android.support.test:rules:0.3' must be compile 

The build.gradle is attached FYI. It is working but unfortunately, the performance is still unacceptable. Even though the Gradle daemon is enabled, dynamically generating android.productFlavors is very slow and consumes more than 2GB memory (seems like the daemon) on MacBook Pro 2015 with Intel Core i5 2.7GHz and 8GB RAM. The build.gradle is attached FYI where each flavor is generated in term of a given configuration. The Gradle sync takes 3 to 4.5 minutes to complete around 300 flavors (debug+release) whenever there is a small change of the script which is hard to accept. Hopefully, this can be solved by improving the flavor creation process.

Essential Instructions to Install Custom Recovery on Galaxy S2

A custom recovery allows to install a custom ROM with adb sideload by disabling signature verification. This tutorial is for Galaxy S2 on OSX. The Android fastboot is not applicable for Samsung devices.

Prep.

1. install the Android SDK and set PATH to platform-tools/
2. download and install Heimdall to flash
3. download CWM for Galaxy S2 AT&T or others models here

Instructions

1. unzip CWM to have zImage in the current directory
2. turn off the device
3. press Power + Volume Down + HOME to turn on the device
4. press Volume Up to continue to enter the Download mode
5. type the following command to flash with the custom recovery
   
   $> sudo heimdall flash --KERNEL zImage --no-reboot 

NOTE

• The custom recovery allows to install a custom ROM with adb sideload.
• If failed with error messages, turn off the device and retry.

OSX Command Line Tools 6.3 Fails Compiling Open Source Packages and C++

Along with the recent release of OSX 10.10.3 and Xcode 6.3, the Command Line Tools 6.3 is available to update from the AppStore. However, the update may fail the compilation of open source packages such the Valgrind whose configure script fails to determine if the compiler is based on LLVM. Even though it is possible to modify the script to pass, the compilation still fails due to 64/32-bit absolute addresses. In general compilation of c++ code, the Missing c++ header <__debug> after updating OSX Command Line Tools 6.3 is probably the most annoying. There are some workarounds are posted on the thread following the link. The issue is also verified by Apple on their developer's forum. Currently, downgrading to 6.2 should make sure everything works as usual.

Proper Usage of Java 8 Parallel Stream

Java 8 stream incorporates parallel constructs for ease of speedup over collection of items. However, it is not guaranteed unless used appropriately. Here are the justifications by Dough Lea1.

In terms of workload

Java 8 parallel stream speeds up sequential work processing by forking threads to exploit potential parallelism but implicit thread setup cost that may weigh down the expected benefits. The total workload estimation from sequential processing is to multiply $N$ by $Q$ defined as follows. Only when $NQ \geq 10000$ is it worth it.

• Assume there are $N$ elements to process in the source collection
• Assume work function $F$ cost $Q$ by lines of code or statements

Startup

• Power control slows down the startup of cores with overhead imposed by JVMs, OSes, and hypervisors.
• Too fine grained work splitting causes startup cost to dominate the parallel processing benefits.
• Random accessible data structures expose more parallel processing speedup over linked lists, blocking queues and IO-based sources for lower access overhead.

Concerns

1. JVMs may not figure out sensibly and deliver uniform speedup in general so that Java 8 Stream simply delegates the decision making to users.
2. Collections may weigh the pros and cons to return a sequential or parallel stream interface selectively in term of some cost measure.
3. Sequential I/O and synchronization tasks should be avoided.
4. I/O sources require custom development of Stream interfaces.
5. Overhead in sequential processing is likely to be magnified in parallel processing in the following aspects.
   
   • cache-locality
   • garbage-collection rates
   • JIT compilation
   • memory contention
   • data layout
   • OS scheduling policies
   • the presence of hypervisors

Full Fees Reimbursement Now!

Android ART Runtime might not Benefit Apps Running Native Code

A recent experiment on the performance of Android apps Android indicates the ART runtime might not significantly benefit apps already running native code. The benchmark app Speaker Identifier computes MFCCs for voice recognition which are usually computation intensive for mobile devices and implementation in native code is a typical solution. Here are the resource usages derived from implementations in two stream processing toolkits, ESMS and StreamIt on Nexus 7 2013 w/ and w/o ART enabled. As is shown, the CPU utilization (CPU time / real time) w/ ART in contrast with Dalvik even increased slightly, implying the pre-compilation overhead, and 5MB more RSS (max. runtime memory) usage. Though, apps implemented and running mostly in Java should still gain performance improvements, developers working on native performance enhancement remain.

Setup

Nexus 7 2013, Android 4.4
Audio format: 44.1 KHz, MONO
Buffering: 0.04s

ESMS Dalvik

200.18 real, 29.49 user, 0.02 sys, 14.74% CPU
RSS: 26734592, Text: 0, Data: 0, Stack: 0
Page faults 0, reclaims: 135
Swaps: 0, Voluntary: 9848, Involuntary: 3049

ESMS ART

200.21 real, 28.97 user, 1.03 sys, 14.98% CPU
RSS: 31498240, Text: 0, Data: 0, Stack: 0
Page faults 0, reclaims: 118
Swaps: 0, Voluntary: 9844, Involuntary: 2475

StreamIt Dalvik 

200.23 real, 48.74 user, 1.01 sys, 24.85% CPU
RSS: 27365376, Text: 0, Data: 0, Stack: 0
Page faults 0, reclaims: 218
Swaps: 0, Voluntary: 9828, Involuntary: 3612

StreamIt ART

200.20 real, 51.46 user, 0.02 sys, 25.71% CPU
RSS: 32129024, Text: 0, Data: 0, Stack: 0
Page faults 0, reclaims: 200
Swaps: 0, Voluntary: 9828, Involuntary: 3230

Dict Eye Demonstration

This app intended to integrate with Google glasses complements our eXtream Language Learning system (xLL). Imagine the camera serves as our eyes to capture vocabulary from all kinds of visual media. We demonstrate words and phrases from subtitles can be recognized according to a specified learner's level and show definitions in real-time. Vocabulary recognition statistics are collected for users to review in flashcards with spaced repetition after finishing watching the media. The real-time text tracking is supported by Qualcomm Vuforia.