Hello, Native Android World!

I just thought I would post my experiences with creating an Android application that uses JNI to call native code.

First of all, create a regular Android project in Eclipse, following the Hello Android tutorial, except
  • change the project name to HelloNativeAndroid
  • change the class name to be HelloNativeAndroid
  • change the package name to be com.christopherfriedt.android, or something similar
Then change your HelloNativeAndroid.java to be something like this:

package com.christopherfriedt.android;

import java.io.*;
import java.util.zip.*;

import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.widget.TextView;

public class HelloNativeAndroid extends Activity {

private native String greet();

/** Called when the activity is first created. */
public void onCreate(Bundle savedInstanceState) {
TextView tv = new TextView(this);
tv.setText( greet() );

static {

String pkg = "com.christopherfriedt.android";
String cls = "HelloNativeAndroid";
String lib = "libHelloNativeAndroid.so";
String apkLocation = "/data/app/" + pkg + ".apk";
String libLocation = "/sdcard/" + lib;

File f = new File(libLocation);

if ( ! f.canRead() ) {

Log.d( cls, "'" + libLocation + "' not found, proceeding to installation" );

try {

ZipFile zip = new ZipFile(apkLocation);
Log.d( cls, "found ZipFile " + apkLocation );

ZipEntry zipen = zip.getEntry("assets/" + lib );

if ( zipen == null ) {
Log.d( cls, "unable to find ZipEntry '" + "assets/" + lib + "'" );
} else {
Log.d( cls, "found ZipEntry '" + "assets/" + lib + "'" );

InputStream is = zip.getInputStream(zipen);
Log.d( cls, "opened InputStream" );
OutputStream os = new FileOutputStream(libLocation);
Log.d( cls, "opened OutputStream " + libLocation );

byte[] buf = new byte[4096];
int n;
while ( (n = is.read(buf)) > 0 ) {
Log.d( cls, "read " + n + " bytes from InputStream" );
Log.d( cls, "wrote " + n + " bytes to OutputStream" );
Log.d( cls, "closed OutputStream" );
Log.d( cls, "closed InputStream" );
} catch( Exception e ) {
Log.e( cls, "failed to install native library: " + e );

try {
Log.d( cls, "attempting to load " + lib );
System.load( libLocation );
//System.loadLibrary( cls );
Log.d( cls, "loaded " + lib );
} catch(Exception e) {
Log.e( cls, "failed to load native library: " + e );
Open up a shell in the 'src' directory of your project and run
javac com.christopherfriedt.android.HelloNativeAndroid.java
javah com.christopherfriedt.android.HelloNativeAndroid

Make a subdirectory in your Android project, called for example 'C', and then copy the resulting com_christopherfriedt_android_HelloNativeAndroid.h (created with javah), to the 'C' folder.

Next, create the following files:

#include "com_christopherfriedt_android_HelloNativeAndroid.h"

#define GREETING "Hello, Native Android!"

JNIEXPORT jstring JNICALL Java_com_christopherfriedt_android_HelloNativeAndroid_greet
(JNIEnv *e, jobject o) {
return (*e)->NewStringUTF(e,GREETING);

CROSS = arm-softfloat-linux-gnueabi- CC = $(CROSS)gcc STRIP = $(CROSS)strip JDK_HOME = /opt/sun-jdk- PKG = com_christopherfriedt_android CLASS = HelloNativeAndroid DEBUG = CFLAGS = -O2 -pipe -Wall -march=armv4t -mtune=arm920t \ -I$(JDK_HOME)/include -I$(JDK_HOME)/include/linux LDFLAGS = -fPIC -shared -nostdlib -Wl,-rpath,/system/lib ifneq ($(DEBUG),) CFLAGS += -g endif SOBJ = lib$(CLASS).so all: $(SOBJ) $(SOBJ): $(PKG)_$(CLASS).h $(CLASS).c $(CC) $(CFLAGS) $(LDFLAGS) -o $(SOBJ) $(CLASS).c ifeq ($(DEBUG),) $(STRIP) --strip-unneeded $(SOBJ) endif clean: rm -f $(SOBJ) install: all cp $(SOBJ) ../assets

Then run 'make', and 'make install'. Build your Android project, and it will now have libHelloNativeAndroid.so bundled in the .apk file, inside the 'assets' directory (you can easily view the contents of it with unzip -l, because it's just a zip file).

Then install the .apk file using the android debug bridge (adb), with 'adb install HelloNativeAndroid.apk'.

Open the application up on your mobile, or in the emulator, and you should see something resembling the screenshot below.

Some notes:
  • My target was a Neo FreeRunner from OpenMoko, hence the -march=armv4t -mtune=arm920t . Feel free to change that to something like -march=armv5te as appropriate
  • In the Makefile, adjust the path to your JDK as appropriate
  • The rpath argument is necessary so that the native Android linker will know to link the shared object to /system/lib/libc.so, which is from the Bionic C library
  • The -nostdlib option is required so that the shared library does not require libc.so.6, which would actually refer to glibc
  • The shared library will be extracted to /sdcard/libHelloNativeAndroid.so, so you'll need that folder to exist and be writable on your device

  • http://android.wooyd.org/
  • http://honeypod.blogspot.com/2007/12/shared-library-hello-world-for-android.html


Mac OS X on a Dual-Core ARM-Powered Netbook?

With all of the hype over ARM-powered netbooks recently, they seem to be here to stay. Basically all of the major companies are jumping on this opportunity; we have the ARM licensees such as TI, Marvell, Qualcomm, and FreeScale, as well as major operating system providers such as Google (i.e. Android), and Microsoft. Even third-party software vendors like Adobe (i.e. Flash) are jumping aboard.

 The ideal silicon solution is a system-on-a-chip (SoC) maybe accompanied by an external graphics  co-processor (if it's not already integrated). For ARM architectures, that basically means 1 or 2 chips to power the entire computer versus Intel's 3, 4, 5, etc. Peripheral devices aside, ARM architectures use an order of magnitude less power than equivalent Intel architectures. What that means, is that the computers we use for our daily tasks, including document / internet activities, multimedia, programming, numerical analysis, etc, will have no fan, no heat-sink, and enough battery power for 10 times the active computing or standby time as Intel-based devices.

Now, I came across an article that I think actually has some merit. Apple could potentially become the next big-time ARM licensee and chip fabricator! Considering their recent acquisition of P.A. Semi and their huge successes with the iPod and iPhone (both ARM devices), they would technically stand to save millions by designing and fabricating their ARM chips in-house rather than purchasing them from outside vendors. Now in terms of porting the OS X to an ARM device - piece of cake. The core of the Apple operating system was designed from the start with portability and inheritance in mind. Their software is already pre-built and packaged in a universal binary format. With all likelihood, all they would need to do is highlight a check-box in XCode to build OS X for the ARM.

Honestly, I've never owned any apple products other than a second-hand 4th generation iPod that I lost on my last flight, mainly due to the prices, but if Apple decides to make a competitive move in the netbook market, then such a device might be the first Apple computer that I would buy, if the price is right. 

To elaborate - I'm a really big fan of the TouchBook from Always Innovating, Inc, especially with the detachable keyboard, and touchscreen / tablet form factor. If Apple could do the same, with a unibody aluminum case, have nice illuminated keys, and throw in that always-on 3G HSDPA modem that Qualcomm has in their Snapdragon, then I would be 100% in. In that case, I would very likely be willing to cough up another hundred for what I see as the ideal netbook. Of course, this could draw the power ratio to something like 1/7 instead of 1/10 when compared to an Intel netbook, but that still makes a very, very big difference.

On a final note, in 2010 consumers will see the dawn of when ARM chips actually incorporate two applications processors (aside from radio, DSP, Graphics, etc), much like the 'Core Duo' from Intel. Apple could incorporate two ARM cores, in order to retain that same UI responsiveness that Apple has been so well known for in the past.

Below is a block diagram [via Engadget] of the new ARM Cortex A9 chips that will begin to appear in 2010. The Cortex line of ARM processors was a step in a slightly different direction, being the first ARM devices to support out-of-order execution (OoOE), and although ARM chips have supported single-instruction-multiple-data (SIMD) since the v6 instruction set was introduced, OoOE will boost ARM performance to a level closer to Intel processors, which have traditionally used both OoOE and SIMD (as MMX). OoOE represents instruction-level parallelism while SIMD represents data-level parellelism. It should be noted that both of the aforementioned optimizations are independent of each other as well as independent of instruction pipelining. However, having pipelining, OoOE, and SIMD on the same chip leads to a exponentially increased complexity, resulting in a very large and necessary amount of silicon to reduce data collisions. This is the primary reason that Intel chips have been had such a long history of being power-hungry. Hopefully, this won't have too large of an effect on the power efficiency of future ARM chips.


Samsung i7500 Galaxy from O2 Germany

I thought I would post a link I found to a PDF on O2's website that states what the price of the Samsung i7500 with Android. The flyer says that it will cost 367€ without a contract.

Check it out here. Some updates are on the O2Online.de blog, saying that it should be available either this week or next.

I hope I won't be out of luck if I ask for it with an english UI :)

Update: Nooooooo.... I was just checking out a youtube video preview of the i7500 and discovered a horrible design decision on the part of Samsung. In spite of having designed the  device with a 3.5mm audio jack (thank you Samsung!) they used one of those super annoying, hard-to-find, flat USB jacks.

The flat USB jacks are horrible and tend to break quite easily. It's also not saving any space as there is a huge 3.5mm jack directly beside it - the whole point of the flat USB connectors is that they're supposed to be used when thickness is an issue.

Read this, and just know that I'm shaking my head 'no' right now in disappointment.

Incidentally, has anyone found out of there is a regular Mini USB connector with the same pinouts as the flat type? I wouldn't mind just soldering out the old one and putting in a standard Mini USB jack.


NVidia Prefers WinCE to Android

There have been hordes of ARM-powered netbooks that have been popping out of the woodworks of Computex this year. One of which was touting the new NVidia ARM Tegra chip.

Here's a link to an article on Slashdot which reports that NVidia is not ready to back Android as a capable platform for Netbooks.

I unfortunately say that I must agree - although its not completely Google, or the Open Handset Alliance, or Linux that is truly at fault - or NVidia for that matter.

The problem is that NVidia would need to expose yet another kernel and user-space ABI (for their latest, integrated Tegra GPU no-less), and they are not prepared to do so. Aside from that, Android performs much of the hardware acceleration (a.k.a. DSP algorithms) for graphic and audio in a completely re-done set of non-portable libraries (the last time I saw the code), rather than using a single, portable abstraction layer such as OpenGL.

My recommendation? End-users should stick with WinCE (as well as the NVidia-modified UI) that will ship with the NVidia-based netbooks - IF THEY CHOOSE TO BUY A NETBOOK THAT USES AN NVIDIA TEGRA CHIP. Certainly, there are many other, more mature ARM chip vendors that will be offering netbook platforms (e.g. Qualcomm, TI, etc).

However, for almost all other ARM cores with unencumbered ABI's and API's for hardware acceleration - by all means use Android! The Android community, which is composed of literally thousands of developers, will have an exponentially greater ramp-up on new technology and software integration speed than NVidia & MS will, as single entities. Plus, as we have seen in the past, the release cycle for Android will likely be more frequent and since it's Open Source. Furthermore, there is less likelihood that Android will fall behind and become unmaintained (which was the whole purpose of the OHA in the first place), while the NVidia & WinCE combination will likely become unsupported and outdated at some point.


Canada Rejects Business Method Patents

Here's a link to an interesting article by Michael Geist [via Slashdot].

I completely agree with the ruling, and am very glad that we still don't patent software in Canada.


More From Computex. The Green Revolution of Computing Begins

One word: Wow!

For basically as long as I can remember, I've been interested in low-power computing. The combination of environmental awareness, plus the ability to understand how things work (i.e. engineering), essentially equates to my urge to want to make the universe more energy efficient. This is the reason why I've been such a big fan of ARM cores for so many years, and also why I've been following the progress of ARM and Linux together. Linux is basically the only publicly-available, fully-featured OS for alternative architectures such as ARM(ok, BSD too), which is why I consider Linux as pivotal for the recent achievements of ARM and their licensees. Having seen the Qualcomm-powered Netbook only a few days ago, I am no longer hesitant to say, that

Linux has enabled ARM to potentially overcome Intel in the PC market

Slashdot posted this yesterday, and I see no shame in admitting I read it there first. Computex has yet again unveiled what I consider to be the future of mobile computing and traditional workstations. Take a few minutes and please watch these videos. What you'll see is that several well-known semiconductor companies (Freescale, Nvidia, Qualcomm, ... Samsung?) plus many new and established manufacturers, have decided that it is time to bring ARM devices to the desktop.

As many engineers are already aware, ARM chips generally use < 1W of power, and entire systems often consume < 5W. These ARM chips run in the GHz range and offer more than enough computational power for day-to-day tasks, multimedia applications, and now even 3D gaming. When we compare the power consumption of about 5 W for a power-hungry ARM system, with the power consumption of a 300W office computer, the greener choice is clear.

A typical Intel-powered laptop or workstation (see x86 architecture) can often consume power in the range of 250-400W, when hard disks, optical drives, and expansion cards are taken into consideration. The most power-efficient x86-systems can run at about 30W. Therefore, the power savings using an ARM-based system can be between 100 times (in the most optimistic case) and 10 times (in the most conservative case) - but always in the favour of ARM systems.

Although the economy is on everyone's minds these days, energy is probably going to be one of the hottest markets in the next decade (and arguably now). I predict that we are likely to see the Green Revolution of Computing within the next few years. Power-efficient chips, such as those based on ARM, MIPS, and PowerPC architectures, will likely start replacing Intel chips on a massive scale. It's likely that this will first happen in the home, and then it will make its way into businesses. Businesses typically rely on 'legacy' applications and the cost is just to high to redesign most programs right away, so we will likely see the business adoption of Green Computing later on, hopefully driven by some kind of government incentive program.

ARM chips are typically designed for a single-user-load, and aren't necessarily the best thing for professional video editing, high-demand servers, extreme gaming, or scientific computing - at least not yet anyway. Of course, adding optical or magnetic-disk drives to any ARM system would increase the average power consumption of the device, but not as much as it would in the case of a PC, as most of required components for ARM are integrated onto a single chip, and not contained in a different chipset altogether. But isn't physical media becoming almost irrelevant these days, with the increased tendency toward cloud computing?


Qualcomm SnapDragon Powered EEE PC Surfaces at Computex

Computex 2009 was host today to the newest member of the EEE PC family, powered by the Qualcomm SnapDragon system-on-a-chip and Google's Android OS for mobile devices. The Qualcomm Snapdragon SoC incoroporates an ARM11 core operating ag 1 GHz (future models will be running at 1.3 GHz), an integrated 600 MHz DSP (a coprocessor for math, audio, and 3D acceleration), as well as embedded hardware video codecs, enabling this processor to support HD video of 720p (later models with 1080p). This netbook also offers always-up connectivity with an integrated internationally-compatible 3G modem, as well as the standard 802.11g wireless connectivity. The full spec list is available here. However, the kicker in favour of ARM-based netbooks is their power efficiency. The Qualcomm-powered EEE PC is expected to boast a battery life of 8 to 10 hours on a single charge!

ARM based processors are what power 99% of today's cellular phones and mobile electronics, such as the iPhone. As one might expect, there is no room for a heat sink or fan in a mobile phone. Therefore, ARM engineers and their licensees have taken power efficiency to a whole new level with this technology. Aside from the impressive multimedia and gaming capabilities, and like most ARM-based SoCs, all of the transistor logic for the CPU, co-processor, and peripheral devices is integrated onto a single wafer of silicon, hence the term 'system-on-a-chip'. Its as if the video, sound, network, PCIe controller, memory controllers, etc, etc, etc, were crammed onto a single package. For comparison, a similar netbook platform, based on the Intel architecture, would occupy at least three, but more commonly four or more chips, resulting in a drastically larger amount of power dissipated as heat.

The 1GHz barrier for ARM chips was first traversed commercially by Marvell, with their Shiva-Plug. Texas Instruments had reached milestones even earlier with their OMAP line of chips which power devices such as the BeagleBoard development board and the OpenPandora mobile gaming platform. The Qualcomm-powered EEE PC is not the first ARM-powered netbook though; some people may still have their eyes on the Always Innovating TouchBook, which is also powered by the familiar OMAP processor. However, if ASUS blesses this marriage of ARM and Android in their cathedrals of manufacturing, then the new Qualcomm-powered ASUS EEE PC might be the first ARM-powered netbook that hits the mass market.