1

I am fighting to run a fully native code as C++ OpenGL ES in NDK.

The idea is to completely avoid the need to have in the Android project the folder /src with lots of java classes interfacing the process, hence boosting the embedded system speed and performance. So, we are going to have the whole program as native C++ under /jni.

It requires the use of Android NativeActivity - see for example: http://www.srombauts.fr/2011/03/01/android-2-3-nativeactivity and Android NativeActivity .

For that, the /src is deleted, and also the AndroidManifest.xml is moved to the root of the project and modified accordingly:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.packtpub.program3D"
    android:versionCode="1"
    android:versionName="1.0" >

    <uses-feature android:glEsVersion="0x00020000"></uses-feature>
    <uses-sdk android:targetSdkVersion="15" android:minSdkVersion="15"></uses-sdk>

    <application
    android:icon="@drawable/ic_launcher"
    android:label="@string/app_name" >

    <activity android:name="android.app.NativeActivity"
        android:label="@string/app_name">
        <meta-data android:name="android.app.lib_name"
            android:value="program3D"/>
        <intent-filter>
            <action android:name="android.intent.action.MAIN"/>
            <category
                android:name="android.intent.category.LAUNCHER"/>
        </intent-filter>
    </activity>

    </application>
</manifest>

The "uses-feature" in AndroidManifest.xml must be specified for "glEsVersion" parameter as "0x00020000", otherwise NDK will use the default 1.0 version.

In Android.mk, the program should have android_native_app_glue, including it as parameter to compile and build:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE    := program3D
LOCAL_SRC_FILES := com_packtpub_program3D.c program3D.c
LOCAL_LDLIBS    := -landroid -llog -lEGL -lGLESv1_CM
LOCAL_STATIC_LIBRARIES := android_native_app_glue
include $(BUILD_SHARED_LIBRARY)

$(call import-module,android/native_app_glue)

The C/C++ code is placed in /jni/Main.cpp. Here you can access a template program useful for test purposes, which is placed in Main.cpp: http://developer.android.com/reference/android/app/NativeActivity.html .

Building and compiling gives no hitch, and just went fine. Here is the output:

**** Build of configuration Default for project program3D ****

ndk-build NDK_DEBUG=1 V=1 all 
rm -f ./libs/x86/lib*.so ./libs/armeabi/lib*.so ./libs/armeabi-v7a/lib*.so
rm -f ./libs/x86/gdbserver ./libs/armeabi/gdbserver ./libs/armeabi-v7a/gdbserver
rm -f ./libs/x86/gdb.setup ./libs/armeabi/gdb.setup ./libs/armeabi-v7a/gdb.setup
Gdbserver      : [arm-linux-androideabi-4.4.3] libs/armeabi/gdbserver
mkdir -p ./libs/armeabi
install -p /opt/android/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/gdbserver ./libs/armeabi/gdbserver
Gdbsetup       : libs/armeabi/gdb.setup
mkdir -p ./libs/armeabi
echo "set solib-search-path ./obj/local/armeabi" > ./libs/armeabi/gdb.setup
echo "directory /opt/android/android-ndk-r7/platforms/android-14/arch-arm/usr/include /opt/android/android-ndk-r7/sources/android/native_app_glue /opt/android/android-ndk-r7/sources/cxx-stl/system/include jni" >> ./libs/armeabi/gdb.setup
Install        : libprogram3D.so => libs/armeabi/libprogram3D.so
mkdir -p ./libs/armeabi
install -p ./obj/local/armeabi/libprogram3D.so ./libs/armeabi/libprogram3D.so
/opt/android/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-strip --strip-unneeded  ./libs/armeabi/libprogram3D.so

**** Build Finished ****

Great! Right? Not exactly.

When asked to run... it simply does not launch. Instead in LogCat only appears the following encryptic message and the program does not load or run in the device:

 system_process : ThrottleSercie : unable to find stats for iface rmnet0

What can be missing, given the fact that the program debugged and compiled nicely.

Someone may have any suggestion? All comments are highly appreciated.

Community
  • 1
  • 1
ThreaderSlash
  • 1,313
  • 3
  • 27
  • 43

1 Answers1

1

I think that logcat message is a red herring.

Your JNI library appears to be named libprogram3D.so yet you are calling it "droidblaster" in the manifest XML (which is what the OS will use to try to load the .so). Try changing one so they match.

Reuben Scratton
  • 38,595
  • 9
  • 77
  • 86
  • Hello Reuben... I checked and updated it properly as you suggested. The output is still the same. – ThreaderSlash Feb 24 '12 at 13:23
  • Put a line of debug trace in your module entry point. If it doesnt appear in logcat you know the .so is not being loaded. – Reuben Scratton Feb 24 '12 at 13:58
  • I already put "ndk-build NDK_DEBUG=1 V=1 all". Where and what other extra parameters can be used to track the problem down? – ThreaderSlash Feb 24 '12 at 14:08
  • "Parameters"? I said you should verify that the module entry point is being called. In your case that's the C function android_main(struct android_app* state). If it's not being called, you know your library's not being loaded. If it *is* being called you know the problem is something in your app. – Reuben Scratton Feb 24 '12 at 14:14
  • I put a breakpoint right at the very entrance point of android_main. It is not being called. Any idea why is it not being called? – ThreaderSlash Feb 24 '12 at 14:35
  • Because your .so module isn't being loaded? Because setting a breakpoint doesn't work? No way to know which. That's why I said to use a trace statement. – Reuben Scratton Feb 24 '12 at 14:41
  • Hi Reuben.. Thanks for your comments. Just solved the puzzle. In Android.mk was necessary to add /jni to LOCAL_STATIC_LIBRARIES. After I have done it, the program built, launched and run in the android device. – ThreaderSlash Feb 25 '12 at 15:52