CODEWITHSUNDEEP
androidandroid-ndk
elcuco
elcuco

Reputation: 9208

NDK build C++ only application

I am trying to build a native daemon on Android. The purpose to to control some specific hardware, and Java applications will be able to communicate to this daemon using sockets.

I have been using cmake meanwhile to compile my libraries, demos and the real daemon (which works fine BTW). I am now trying to do 2 different things:

  1. Build the same apps using ndk-build.
  2. Port the C++ daemon to an Android service, by making JNI calls very similar to the way the c++ daemon works.

As far as I understand, ndk-build cannot make native applications, but only native libraries, which in turn can be loaded by the Java GUI... am I correct? For step1 I don't really need java (and I have proven it already), but I have yet found a way for ndk-build to spit an elf application.

For reference - I am using cmake, as described here: http://opekar.blogspot.com/2011/06/android-cmake-is-much-easier-in-ndk-r5b.html

This way I can have builds for "normal" linux, and also android using out of source builds. Quite nice hack if you ask me.

Upvotes: 1

Views: 5039

Answers (3)

xperroni
xperroni

Reputation: 2814

An alternative is to use the script make-standalone-toolchain.sh bundled with the NDK to create a stand-alone toolchain, then use it to compile your project. The shell code below illustrates how to use it:

# Assumed path to the NDK, change it to suit your environment.
NDK_HOME=$HOME/bin/android-ndk-r8e

# Desired API and NDK versions and destination folder of
# the stand-alone toolchain, change them to suit your needs.
api=14
ver=4.7
folder=$HOME/bin/android-$api-ndk-$ver

# Create folder if it doesn't already exist.
mkdir -p $folder

$NDK_HOME/build/tools/make-standalone-toolchain.sh \
    --toolchain=arm-linux-androideabi-$ver \
    --platform=android-$api --install-dir=$folder

Running the lines above will generate a new stand-alone toolchain at $HOME/bin/android-14-ndk-4.7, which you can then use as any regular C/C++ cross-compilation toolchain.

The advantage of working with a stand-alone toolchain is that it makes cross-compiling Linux projects to Android a breeze; see for example my port of Valgrind to Android ARMv7.

Upvotes: 2

elcuco
elcuco

Reputation: 9208

As mentioned by @Mārtiņš Možeik in one of the comments, this pice of Android.mk will work:

LOCAL_PATH       := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE     := my_daemon
LOCAL_C_INCLUDES := src
LOCAL_SRC_FILES  := src/daemon.c
include $(BUILD_EXECUTABLE)

One thing I do notice is that the binary produced by this "makefile" is 130k, while the binary produced by cmake was ~40 kb. This is because I used -s as a C_FLAG and then gcc will strip the produced object on the fly. This can be done later on by calling $NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-strip or the corresponding strip for your arch.

As I have not found documentation of this feature on the internet, some more words:

  • This works quite good, no problem here :)
  • This must be saved in a file called jni/Android.mk.
  • The code must be saved inside the JNI directory
  • If your code is outside of the jni directory this get ugly, but not impossible. You just need to prefix the code with the corresponding prefixes, don't forget to modify also the include path. This is left to the reader as an exercise.
  • Still unsure why the code generated from Android build system is larger then the code generated by cmake. I previously said that strip is not called - but it is called before the *.so are copied to the lib directory.
  • Still don't know how to package that binary into an android package, and not even how to run it (for example when the system is up) without modifying the Android code. I assume I can write a Java service that starts on boot and then execvps the daemon.

Upvotes: 1

Goz
Goz

Reputation: 62333

Your option 2 is the only way to do it AFAIK.

Upvotes: 0

Related Questions