Archive for October, 2015

How to build Android SDK samples using Gradle?

First, my environment is Ubuntu 14.04 LTS, and I would like to compile Android SDK samples. The present write-up is a follow-up to this:

where compilation is done using the traditional “ant”, at present is a version using “gradle”.

First go to the Android sample directory and issue the compilation command:

cd /opt/android-sdk-linux/samples/android-23/testing/ActivityInstrumentation

./gradlew build

Got error, and so I created a file (as requested by error) called “” with the following content (just one liner):


And recompile, and got error again.

FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ‘:Application:compileDebugJava’.
> invalid source release: 1.7

Meaningless error message, but a intuition just arrive, checking java version:

java -version
java version “1.6.0_45”
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

Possibly this version is not right, though it is the right version (in the past, not sure now?) for compiling AOSP. And anyway, after updating to java7:

export PATH=/usr/lib/jvm/java-7-openjdk-amd64/bin:$PATH

(where the above “java-7-openjdk” comes from is via “sudo apt-get install openjdk-7-jdk”.)

now the entire sample builds to completion without error:

./gradlew build
:Application:preBuild UP-TO-DATE
:Application:preDebugBuild UP-TO-DATE
:Application:preReleaseBuild UP-TO-DATE
:Application:compileReleaseUnitTestSources UP-TO-DATE


Of course, if you want to debug what are the root cause of error, another way is to generate verbose output with the following command:

./gradlew build –stacktrace –info –debug

Example 2

First cd to directory:

cd /opt/android_sdk/samples/android-22/renderscript/BasicRenderScript

Issue the command (after ensuring that “gradlew” command exists):

“./gradlew build”

:Application:compileDebugNdk UP-TO-DATE
:Application:assembleRelease UP-TO-DATE
:Application:assemble UP-TO-DATE
Ran lint on variant debug: 49 issues found
Ran lint on variant release: 49 issues found
Wrote HTML report to file:/sda7/android_sdk/samples/android-22/renderscript/BasicRenderScript/Application/build/outputs/lint-results.html
Wrote XML report to /sda7/android_sdk/samples/android-22/renderscript/BasicRenderScript/Application/build/outputs/lint-results.xml


Total time: 19.919 secs

In between above there were some errors, corrections of which are shown below:

In the file “/opt/android_sdk/samples/android-22/renderscript/BasicRenderScript/Application/build.gradle”:

39 lintOptions {
40 abortOnError false
41 }

was inserted inside the android {} tag:

35 android {
36 compileSdkVersion 21
37 buildToolsVersion "21.0.1"
39 lintOptions {
40 abortOnError false
41 }
43 defaultConfig {
44 minSdkVersion 8
45 targetSdkVersion 20
46 }

But many times, the lint errors is not supposed to be ignored by 
adding "abortOnError false" inside build.gradle file.   For example is the error below:

ls -1 /sda7/android_sdk/samples/android-22/renderscript/BasicRenderScript/Application/src/main/res/values/


There is a bug in base-strings.xml, just ensure that there are no aprostrophe inside the CDATA tags, or specifically the following (aprotrophe has been removed):

20 <![CDATA[
23             This sample demonstrates using RenderScript to perform basic image manipulation. Specifically, it allows users
24             to dynamically adjust the saturation for an image using a slider. A custom RenderScript kernel performs the saturation
25             adjustment, running the computation on the device GPU or other compute hardware as deemed appropriate by the system.
28         ]]>

Using the above method I was able to compile successfully 84 of the samples under the “Android-22” directory in “samples”, and 19 failures, which mostly are attributable to lint error:


QEMU how to setup Tun/Tap + bridge networking

The default NAT networking as provided by QEMU’s “-net net -net nic” option (which is the default even if you don’t specify it in qemu’s commad line) will only provide NAT networking.

And in this mode you can only connect out of the QEMU guest, but not into it.

To enable it to have its own IP address, through a DHCP outside the host, it is necessary to setup the QEMU in bridge mode.

To do this:

Inside the linux hosts (I am assuming Ubuntu 64-bit 14.04 host here, for other distro some variation may be needed):

sudo apt-get install uml-utilities
sudo apt-get install bridge-utils

Inside the host’s /etc/networking/interfaces file add this:

        auto br0
        iface br0 inet dhcp
        bridge_ports eth0
        bridge_stp off
        bridge_maxwait 0
        bridge_fd 0

Then issue “sudo brctl addbr br0”.   Check using “ifconfig” that “br0” interface is created:

br0       Link encap:Ethernet  HWaddr bc:ee:7b:8c:53:9a
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

And create this file /etc/qemu-ifup (on the host side) which should have contents like below:

#! /bin/sh
# Script to bring a network (tap) device for qemu up.
# The idea is to add the tap device to the same bridge
# as we have default routing to.

# in order to be able to find brctl
ip=$(which ip)

if [ -n "$ip" ]; then
ip link set "$1" up
brctl=$(which brctl)
if [ ! "$ip" -o ! "$brctl" ]; then
echo "W: $0: not doing any bridge processing: neither ip nor brctl utility not found" >&2
exit 0
ifconfig "$1" up

switch=$(ip route ls |
awk '/^default / {
for(i=0;i<NF;i++) { if ($i == "dev") { print $(i+1); next; } }


# only add the interface to default-route bridge if we
# have such interface (with default route) and if that
# interface is actually a bridge.
# It is possible to have several default routes too
for br in $switch; do
if [ -d /sys/class/net/$br/bridge/. ]; then
if [ -n "$ip" ]; then
ip link set "$1" master "$br"
brctl addif $br "$1"
exit # exit with status of the previous command

echo "W: $0: no bridge for guest interface found" >&2

The “switch=br0” is the only line I modified from original.

And then on the host side:

sudo tunctl -d tap0
sudo tunctl -u tteikhua
sudo ifconfig tap0 netmask

Verify that the command “sudo sh /etc/qemu-ifup tap0” runs without error.   Then doing a “sudo brctl show”:

bridge name    bridge id        STP enabled    interfaces
br0            8000.4ed6f463bc09    no         eth0

The following diagram (from showed the approximate logical traffic flow after the setup.

Inside the QEMU guest, the only thing done is just “dhclient eth0” to initiate the DHCP client seeking a new IP address through the bridge interface, assuming the DHCP server lives outside the host machine.

And if you need to setup another VM guest, just create another tap (eg, “tap1”) interface, and then add the tap to the bridge via “sudo brctl addif br0 tap1” command. And this tap1 and tap0 will appear as independent networking element directly connected to the network.

For a detailed explanation of the above configuration, see:

How to get ethernet networking working for a new motherboard in any Distro?,1.html

Just purchased one of these mobo from Newegg, and after booting up in my Ubuntu 14.04 LTS, including booting up with the CDROM as well – there is always no ethernet NIC detected.

Doing a "sudo lshw", I can see that the ethernet hardware remained "unclaimed", meaning no kernel modules has been loaded that is able to recognize the ethernet hardware.

Exploring further, from the specifications we know the onboard ethernet is Intel I219 gigabit ethernet card. So searching through the latest linux kernel source codes:

/* Make sure clock is enabled on I217/I218/I219 before checking
* In i219, the descriptor rings must be emptied before resetting the HW
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_SPT_I219_LM), board_pch_spt },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_SPT_I219_V), board_pch_spt },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_SPT_I219_LM2), board_pch_spt },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_SPT_I219_V2), board_pch_spt },

It is obvious that I219 is supported by the e1000e kernel module. So you just need to recompile the kernel and bootup with the new kernel/kernel module (e1000e.ko) loaded and problem is solved.

%d bloggers like this: