In my Android NDK project, I have the following structure:
jni/
Android.mk
... (more source files)
new-lib/
Android.mk
... (more source files)
In the top level Android.mk I have include $(call all-subdir-makefiles) as the last line. I suppose now all the native codes including those under new-lib/ should get built when run ndk-build.
But when I run ndk-build command under project root path, only the top level native codes get built, the native code in subdir new-lib/ isn't built at all. Why?
I only work with one Android.mk in which I define all include folders, but I think here you'll find what you need. For what I understand, you need to make sure you are using the LOCAL_PATH in all your Android.mk files like this:
LOCAL_PATH := $(call my-dir)
Related
I have added ndk plugin in Eclipse.
I have imported a NDK project in Eclipse.
But projects requires external .h file from the system, so I have added that folder where .h files files resides by
right click on project-> c/C++ General->Paths and symbols->then click on
include and then click add and given path of that folder
also checked all configurations and all languages.
still when I build the project from Command prompt by moving to path where my project is , then ndk-build I am getting for .h file no such file or directory error.
How can I resolve this issue??
Please help...
Please refer to documentation of LOCAL_C_INCLUDES variable
what you did to add the reference the external headers was only for eclipse, so it correctly resolves all the symbols and files references.
You also need to properly add a reference to these .h inside your ndk configuration files, ie inside Android.mk.
Use LOCAL_C_INCLUDES := path/to/headers in your module, like in this sample Android.mk file:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES := main.c
LOCAL_MODULE := mymodule
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../includes
include $(BUILD_SHARED_LIBRARY)
If your .h files are part of a prebuilt module your own module depends on, use LOCAL_EXPORT_C_INCLUDES inside the prebuilt module instead of LOCAL_C_INCLUDES inside yours.
I found instructions for how to link and use c/c++ code in Android by utilizing the NDK. But I'm searching how call function from third party .so .
For example your prebuilt library is called "libmy.so"
In the project folder of the project you want to use it:
1) create libmy folder in jni folder (jni/libmy)
2) copy your libmy.so here
Then, just create a jni/libmy/Android.mk file:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libmy
LOCAL_SRC_FILES := libmy.so
include $(PREBUILT_SHARED_LIBRARY)
Now in your jni/Android.mk you can write:
LOCAL_SHARED_LIBRARIES := libmy
Then when you do ndk-build, it will copy this library in to libs/armeabi/
After that you can use this library in your C++ code.
You just have to put the .so in your libs/armeabi-v7a folder (or whatever other architecture you have compiled for, like armeabi, x86 etc.) and Eclipse will automatically see it and integrate it into the APK.
Then to access any native functions from the .so in your Java code, you just have to declare it as a native function at the top of your class. For example
protected static native void AKUAppInitialize ();
which can then be called anywhere later in the code like
AKUAppInitialize();
You have to configure your NDK part if you have the source code: look at this tutorial
I'm testing JNI on Android in Eclipse.
I have a simple Android project with one activity. In Eclipse's project explorer, I added:
jni/ folder
Android.mk in the jni/ folder
prng.c in the jni/ folder
The source file is named prng.c because it wraps Crypto++'s random number generator. Crypto++ is already cross-compiled for ARMv7, so I have libcryptopp.so standing by.
When I select Project → Build Project, the library is not built. I've confirmed its not built after cleaning the project, too.
Android-PRNG$ find . -iname *.so
Android-PRNG$
Question: Why is Eclipse not building the shared object? What else need to be done?
Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := prng
LOCAL_SRC_FILES := prng.c
include $(BUILD_SHARED_LIBRARY)
prng.c
Its basically empty at the moment because I can't get javah to run on the Java class file that calls the native methods. I hope to fix that problem next.
#include <string.h>
#include <jni.h>
#include <cryptopp/osrandom.h>
static RandomNumberGenerator& GetPRNG()
{
static AutoSeededRandomPool prng;
return prng;
}
It's actually very easy with ADT for the last couple of years; it was much worse before. The plugin described in the linked post are coming preinstalled; you still need to
1 install NDK
2 set the path to it in Preferences/Android/NDK menu
3 right click on your Android project, Android Tools/Add Native Support
... and now you are all set.
I'm trying to build a project using the android ndk (on Windows), and I'm having some issues specifically with the source files (LOCAL_SRC_FILES in the Android.mk)
I'm trying to use relative paths to a parent folder such as
LOCAL_SRC_FILES := ../../../src/main.cpp
And when running ndk_build.cmd, it outputs the following error:
Compile++ thumb : GTP <= main.cpp
The system cannot find the file specified.
make: *** [obj/local/armeabi/objs/GTP/__/__/__/src/.o] Error 1
So I tried using absolute paths:
LOCAL_SRC_FILES := D:/Path/To/src/main.cpp
Unfortunately this doesn't work because the : causes issues on windows
Is there any way I can specify source files in a relative directory (or absolute)? The reason I am asking is because I want to avoid making a symbolic link to the src folder if possible.
According to ndk documentation it is recommended to use relative paths and the following macro (Android.mk uses syntax of make files):
LOCAL_PATH := $(call my-dir)
An Android.mk file must begin with the definition of the LOCAL_PATH variable.
It is used to locate source files in the development tree. In this example,
the macro function 'my-dir', provided by the build system, is used to return
the path of the current directory (i.e. the directory containing the
Android.mk file itself).
So you can replace your LOCAL_SRC_FILES with something similar to:
LOCAL_SRC_FILES := $(LOCAL_PATH)/../../../src/main.cpp
The easiest way to work with source files spread across many directories, is to compile separate static libraries for each directory or group of directories. In NDK, these libraries are called "modules". For each module, you specify LOCAL_SRC_PATH in Android.mk. LOCAL_SRC_FILES are relative to this path. The caveat is that LOCAL_C_INCLUDES etc. are relative to project root directory (usually, the one above the jni directory).
You can have many Android.mk files in your project, but you can build many modules with single Android.mk.
Try this:
LOCAL_PATH:=$(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES := YOUR_SRC_IN_LIB_JNI
I'm currently implementing a custom Logging mechanism that I need to be accessible from both native and Java code. The fundamentals of the logging are implemented in C/C++ with a Java wrapper, and the two together are being built as an android Library Project.
The issue at hand is that while my Java code can access the Library project output, there doesn't seem to be a way for my native code to access the native .so or headers from the Library project. Is there an additional step I'm missing or is this just a limitation of the current ADT? More specifically, is there a makefile/eclipse configuration that will address the things I'm used to getting out of Library projects in general? (Build .so as needed, import rebuilt .so, import relevant headers for c/c++ compilation, etc.)
I don't think it's a limitation. We are supposed to declare native code dependencies in Android.mk and Application.mk
Worked out a way to get what I wanted - most of the information is (of course) in the NDK documentation, but what I was trying to do isn't 100% supported within the ADT. It should also be noted that I'm currently stuck developing in a windows environment, so much of this might be easier or unnecessary in Linux. The first key is the $(call import-module ...) macro. Within your library project, move the source files and the Android.mk folder into a named directory you can locate later. My Library project directory looked like this:
MyProject
> src
> res
v jni
- Application.mk
v MyLib
- source.cpp
- source.h
- Android.mk
I also had to edit my Application.mk to point to the project:
APP_PROJECT_PATH := <path-to-my-project>
APP_BUILD_SCRIPT := $(APP_PROJECT_PATH)/jni/MyProject/Android.mk
Annoyingly, this broke my Android.mk in ways unforseen until I added a ./ to my source files. Also you need to export your includes for linking:
LOCAL_SRC_FILES := ./source.cpp
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)
Ensure that the system path variable NDK_MODULE_PATH is set to include your library's JNI directory, e.g. <path-to-my-project>/jni (Note: I had to restart eclipse after I did this).
In the receiving application's Android.mk file (the one you'd like to link natively to your app), import the module:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := MyNativeProject
LOCAL_SRC_FILES := source.cpp
LOCAL_CFLAGS := -DANDROID_NDK -g -std=c99
LOCAL_SHARED_LIBRARIES := MyLib
include $(BUILD_SHARED_LIBRARY)
$(call import-module,android/native_app_glue)
$(call import-module, IntelLog)
At this point everything built perfectly, but the APK packager didn't like the generated .so binary being included twice (once from the Library project's natural import process, and again from the import-module call). To solve this, clean the library and don't build it again! the import-module call will build the .so and import it into your project. (Obviously, if your project only requires the Java API, you would need that .so file to be built). Congratulations! you have a functional (if not straightforward) build process with a hybrid native/Java Library