Archive for category Native (JNI)

Google have just released the latest NDK. The biggest change is support for OpenGL ES 2.0…

“Android 2.0 (API level 5) or higher can now directly access OpenGL ES 2.0 features. This brings the ability to control graphics rendering through vertex and fragment shader programs, using the GLSL shading language.”

As mentioned on Forbes, ‘Mobile Games On Android Haven’t Caught On Yet’. This is partly because there aren’t that many great games. Part of the reason is that Java isn’t great for creating real-time games and you really need native coding to achieve high frame rates. Access to (native) OpenGL ES 2.0 should encourage creation of some great games and might even eventually help some games get ported from iPhone.

As it happens, I have recently been doing some development with the previous NDK and have two tips to help you get set up a bit quicker if you are developing under Windows.

• When you install Cygwin ensure you include (tick) ‘make’ in the install

• Cygwin maps your hard drives under /cygdrive/c/, for example /cygdrive/c/ for c:\. However, if you cd to cygdrive you won’t see c listed. If you include it in a path it works.

I previously posted about writing native code.  Since then, I have come across the Google ndk group. It provides some more information on Google’s plans and some messages from people trying to get native code working without an official ndk.

The first release of the ndk (available in 1H2009) will be targeted towards Java application developers who wish to write native code shared libraries to access native code APIs or accelerate portions of their application…

“At first only a small subset of the full set of Linux and Android APIs will be supported, but in later releases additional APIs will be supported. The initial goal is to support JNI shared libraries written in C or C++ that link with the Android versions of libc and libm. In a future release we hope to support linking with OpenGL ES and audio libraries, which should enable high-performance games. The NDK can also be used to compile Linux executables and shared libraries that only require the subset of Linux APIs that are supported by the NDK. This might be useful for developers wishing to port utility programs to help develop and test their Android applications.”

I have been doing some feasibility work for a client where they wish to write native code on Android. Android OS doesn’t officially support this. Why might someone want to write and run their own native code? I think there are three main reasons…

1. To improve the performance of time or space sensitive operations
2. The port existing code
3. To gain acceess to hardware resources or libraries not available from JAVA

The problem with native coding is that you are exposing yourself to a huge risk whether your application will work on future phones. The existing native libraries (that you need to link with) on the current Android phones are mainly the same as noone (no phone OEM) has ventured beyond the ’standard’ android configuration. However, given time, libraries will change, diverge and in the worst case, Android may even be based on different architecture/platforms causing you to have to ship different native libraries yourself. You are affactively using undocumented APIs that can break on some phones or possibly when the phone firmware is upgraded.

Nevertheless, I see there’s a great need for many companies to port their existing code to Android OS. Many applications have large amounts of their business logic wrapped up in c++ or more commonly c so it can be compiled on ‘any’ platform. Porting the language (to Java) just isn’t feasible for them.

There’s an example of the Java Native Interface (JNI) and how to run your own native exe. The Mandelbrot fractal viewer for Android also provides a full source code example of including native code within an Android .apk. There’s also an article criticising the JNI interface.

According to the Google groups, Google are looking into including the ability to include native code with a Java application in a supportable way, but there are no timescales as to when this might become available.