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.

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.

Inconsistent Working Directory for Unit Tests Triggered from Command-Line Gradle and from Android Studio

With the introduction of the Android Studio, Gradle also gets popular as the default build system. However, there is some inconsistency to run Gradle from the command line and from the Android Studio interface which is quite annoying. Take unit tests in a mult-project for example. A unit test in a subproject accesses a file through a relative path. If triggered from the Android Studio interface menu (right click and run the test), the path is relative to the root project. However, if triggered by the Gradle from the command line, it is relative to the subproject. The default behavior is quite confusing. Fortunately, it is possible to set the working directory thanks to the reply by Jake Wharton. Just go to Run/Configurations and select the Defaults/JUnit. The above figure shows the settings, including the working directory. It is default to the root project. Changing it to $MODULE_DIR$ recovers the inconsistency.

Diigo with Readability =? Highlightable Evernote for Android

When it comes to web clipping, Evernote is strong at clipping selectable web content in a readable format while retaining the styles. However, clipped webpages so far may not be highlightable on Evernote for Android. On the other hand, Diigo is good at highlighting webpages but sucks at clipping in a readable format. As for Readability, it renders a webpage readable but lacks highlight functionality. So, why not marry Readability to Diigo to make the best of both worlds?

Desktop Prep.

1. create accounts on both Diigo and Readability
2. install browser extensions for both
3. go to Readability login and save to Diigo

Desktop Web Clipping

1. stay on the webpage
2. invoke Read Now of Readability extension
3. invoke Diigo extension is save the webpage of Readability

Highlight on Andoird

1. install Diigo app from the Android Market
2. open Diigo app and click the Readability login bookmark
3. log in to your Readability account
4. click the menu bar to come back to the Diigo bookmarks
5. view saved Readability articles you want and highlight with Diigo

PS

• One may think of Instapaper but only 5 highlights for free are ridiculous
• Evernote shared notes are not highlightable for Diigo