Reputation: 403
All the ndk samples only make use of basic C functions declared as extern in the header and defined in the cpp file. Then after including the header file in the C file containing the jni callback, everything works fine.
Is it possible to use C++ classes with the android ndk? My application is not going to be a native activity, it will still have an important java part but it will call native C code for CPU-intensive computation (already written in C++, with classes and other C++ stuff).
Here is my hello-world like strcuture for now:
File "first.h"
#ifndef FIRST_H
#define FIRST_H
class Test
{};
#endif /* FIRST_H */
File "second.cpp"
#include <jni.h>
#include "first.h"
#ifdef __cplusplus
extern "C" {
#endif
jint Java_com_example_twolibs_TwoLibs_add( JNIEnv* env,
jobject this,
jint x,
jint y )
{
Test t;
return 0;
}
#ifdef __cplusplus
}
#endif
And finally Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libtwolib-second
LOCAL_SRC_FILES := second.cpp
include $(BUILD_SHARED_LIBRARY)
Pretty basic but that does not compile. Turning second.cpp in a .c file raises an error when including the header file, I guess this is because it is not a C++ file.
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Test'
Making it .cpp raises the following error:
make: *** No rule to make target `/cygdrive/c/android-ndk-r5c/samples/twolibs/jni/second.c', needed by `/cygdrive/c/android-ndk-r5c/samples/two-libs/obj/local/armeabi/objs/twolib-second/second.o'. Stop.
Any idea how I can make that thing compile?
Thanks
Upvotes: 34
Views: 32167
Reputation: 1
Edit Android.mk
Modify the instances of LOCAL_SRC_FILES and remove the ./ from the begginning of each line.
Upvotes: 0
Reputation: 382502
Run:
ndk-build clean
after you modify a wrong Android.mk
, or else the build may continue to fail even if you've fixed the configuration.
I think this is what the OP meant on this comment.
Upvotes: 0
Reputation: 2533
About your compiling error, seems like you first called it "second.c" and later renamed it to "second.cpp" but the object files still have the "second.c" name in them so before you compile (bdk-build) you need to remove the *.o and *.d files in /cygdrive/c/android-ndk-r5c/samples/two-libs/obj/local/armeabi/objs/twolib-second/ directory
Upvotes: 1
Reputation: 392833
error: expected '=', ',', ';', 'asm' or '__ attribute __' before 'class'
Classic case of missing ';' before the class keyword? Imagine
int functionname(int p)
class X { } ;
This could lead to your compiler message quite easily. A common complicating factor is when it actually looks like
#include "someheader.h"
class X { } ;
and the error is in the last declaration inside someheader.h /or any recursively included file/ ;)
Upvotes: 0
Reputation: 54705
You can use C++ with NDK, but files with C++ code must have .cpp extension.
From ANDROID-MK.html:
Note that the default extension for C++ source files is '.cpp'. It is however possible to specify a different one by defining the variable LOCAL_CPP_EXTENSION. Don't forget the initial dot (i.e. '.cxx' will work, but not 'cxx').
Upvotes: 15
Reputation: 206508
You will have to recompile all the native libraries specifically for Android. You do need the source code for all 3rd party native libs you plan to use simply because Usually when we compile and link these libraries outside Android they are linked to glibc
but unfortunately Android doesn't use glibc
due to liscence and performance issues. Android uses a watered down version of glibc
called libc
. It has matching symbol names to glibc for most of the usual functionalities. But as far as i know the libc doesn't have some functionality related to strings
and it definitely doesnt have some posix
support. If your native libraries are using any of the deprecated functionality you will have to find workaround for those by using alternative functionality supported by libc
and coding your libs accordingly.
Also, as you righty pointed out you will have to use the NDK to interface Java(Android app/fwk) to native world(C++).
Though this sounds pretty simple in my experience compiling native libraries on Android(Android porting) has traditionally been very time consuming with no guarantee of sucesses.
Upvotes: 3