How does one Android NDK library without a Android Project - android

I would like to be able to build a shared library in using the android ndk-build script, but for some reason I get a bunch of errors:
# I have Application.mk and Android.mk in the current folder
ndk-build -C .
Android NDK: Could not find application project directory !
Android NDK: Please define the NDK_PROJECT_PATH variable to point to it.
Is there a way to build the Android shared library with only the source and header files?$$\int$$

Yes, you can write
ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk
But it's much easier to create ./jni directory and put both Application.mk and Android.mk there.

Related

android ndk: specify APP_ABI with cmake

I want to compile some c files for my android project. I'm using NDK with cmake. And I want to generate the .so files for all available CPU types. Most of the tutorials online are based on ndk-build, in which they specify the APP_ABI := all in Application.mk file. How can I do the same with cmake?
My cmake version is 3.18.1
Thanks.
For a "pure" CMake project, this cannot be done with a single generated build tree.
Assuming you are passing a path to a toolchain file to CMake (with -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake), you should also be passing in an ANDROID_ABI argument. For possible values see here
You're then expected to have a separate build dir for each ABI, something like:
MyProjectDir/
build_x86_64/
build_x86/
build_arm64/
build_armeabi/
src/
...
If, on the other hand, you are working with a Gradle-managed project, then the ABI is automatically controlled by Gradle and you only need to worry if you don't want to build for all ABIs.
Build your app as normal, and when you get an APK - open it (it's essentially a ZIP archive). Inside it should be a lib directory containing subdirectories for each ABI.

How to use ndk-build without jni directory?

We are attempting to add first class build support for Android to a C++ library. We want to supply a stock Android.mk, and disgorge it from dependencies like a jni subfolder in an Eclipse or Android Studio project directory. That is, we want to:
cd library-src
ndk-build <options>
In the above, library-src is not NDK_PROJECT_PATH. Rather, its the root folder for the library.
We visited the NDK's help (ndk-build -?), but it did not tell us how to remove the assumptions. We tried the following, but it produced an errors:
$ ndk-build -f Android.mk
Android NDK: Could not find application project directory !
Android NDK: Please define the NDK_PROJECT_PATH variable to point to it.
/opt/android-ndk-r10e/build/core/build-local.mk:143: *** Android NDK: Aborting
Stop.
Attempting to set NDK_PROJECT_PATH results in a similar error:
$ NDK_PROJECT_PATH=. ndk-build -f Android.mk
Android NDK: Your APP_BUILD_SCRIPT points to an unknown file: ./jni/Android.mk
/opt/android-ndk-r10e/.../add-application.mk:199: *** Android NDK: Aborting...
Stop.
And attempting to set APP_BUILD_SCRIPT results in a similar error:
$ NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=Android.mk ndk-build -f Android.mk
Android NDK: Your APP_BUILD_SCRIPT points to an unknown file: ./jni/Android.mk
/opt/android-ndk-r10e/.../add-application.mk:199: *** Android NDK: Aborting...
Stop.
How do we use ndk-build without the jni directory?
Its important that we remove the limitations/assumptions. If we can't remove them, then we can't automate building and testing. If we can't automate building and testing, then we can't add the support because our governance has some QA and testing gates that we won't be able to pass through. (I'm willing to tolerate a manual adb push to test on-device).
I must admit that I don't understand your limitations. Why adding file library-src/Android.mk is OK, but library-src/jni/Android.mk breaks your QA and testing gates. Furthermore, Android.mk is usually not enough to launch a build. Whether you want to choose the STL variation, or ABI, or toolchain, it is natural to define these settings in a different file, Application.mk, which also goes to the jni directory by convention. Add library-src/jni directory, and Android developers will thank you when their tools of trade get upgrades and they can stay with the standard configuration.
But Android build is a very flexible system, and you can achieve literally what you ask for.
The experiments that you made did not work because ndk-build is simply a thin wrapper around GNU make, and treats environment variables with low priority.
ndk-build APP_BUILD_SCRIPT=Android.mk NDK_PROJECT_PATH=.
will most likely simply work for you. If you need more control, you can use something like
ndk-build APP_BUILD_SCRIPT=Android.mk NDK_PROJECT_PATH=. APP_STL=gnustl_static APP_ABI=armeabi-v7a APP_PLATFORM=android-19 NDK_TOOLCHAIN_VERSION=4.9
You can control the output directories, too. See NDK_APP_OUT, NDK_APP_LIBS_OUT.
One last hint: if your global build process is based on make, you can invoke $(MAKE) directly instead of going through ndk-build. It is also OK if you require standalone toolchain to keep platform-independent make logic.

Android NDK refer to external libraries in JNI

I have written C++ file in JNI folder of my application. I am using Windows system with NDK and Cygwin 1.7.I want reffer to CURL library available in Cygwin.How can we refer to external .h(libraries/header) files while creating JNI application in Android?I have created a combined Android and C++ project. But I am referring CURL header file. When I build the project I am getting fatal error: curl/curl.h: No such file or directory issue.
Follow these steps:
Converting from Android project to C/C++ project:
Right click on your project name, go to 'Android Tools' and click 'Add native support'
Adding paths to external .h files:
Right click on your project name, go to 'Properties', under 'C/C++ General', go to 'Paths and Symbols', under 'Includes' tab, add the folder in which your .h file is. Remember to add to all languages and configurations if asked.
Also, since you are in Windows, I think you will need to change your Build command (which is in the 'C/C++ Build' section in project properties) to "bash C:\Development\android-ndk-r8\ndk-build.cmd"
Add the following to your Android.mk:
LOCAL_CFLAGS += -I$/PATH/TO/YOUR/curl.h
LOCAL_LDLIBS += -L$/PATH/TO/YOUR/libcurl.a.for.android -lcurl
The libcurl.a you have installed in cygwin is not usable for android, you need a version targetting android. If you don't have it, build it yourself.
When you get that libcurl.a file, do not forget to copy the headers folder of curl (get into your usr/include/curl from Cygwin) and add this folder to the JNI one in your project, so it knows the headers while compiling.
Which means also referring in your Android.mk :
for the libcurl library
LOCAL_SRC_FILES := libcurl.a
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/curl
and for your C++ files
LOCAL_C_INCLUDES := $(LOCAL_PATH)/include/curl
LOCAL_WHOLE_STATIC_LIBRARIES := libcurl
Please used this tutorial is nice one.
Don't forgot to change this setting after convert project to C / C ++ native project.
Builder Settings to Build Command
bash C:\tools\android-ndk-r8b-windows\android-ndk-r8b\ndk-build
This is my path of NDK you can change this path accordingly your NDK path.

Compiling linked ( not copied ) files using NDK

I'm building an OpenGL based app - writing in native C/C++.
I want to have my native files in a single location and only linked to the project ( so when I edit them in XCode/Eclipse the other project already has the updated files ). However, I can't figure out how to get ndk-build to build files that aren't actually in the JNI folder. Symbolic links ( in OSX ) didn't do the trick.
I keep getting
make: *** No rule to make target `/Developer/SDKs/android-ndk-r7b/build/core/myfile.cpp', needed by `obj/local/armeabi/objs/glHelloArrow/myfile.o'. Stop.
Any ideas?
I build outside of JNI folder on Windows. My Android.mk includes a makefile in a different folder:
LOCAL_PATH := $(MY_WORKSPACE)/path/jni
include $(MY_WORKSPACE)/path/jni/Src.mk
where the actual sources are listed:
LOCAL_SRC_FILES := \
a.cpp \
b.cpp \
etc.
One caveat is - make does not work right with relative paths. Or rather, it does, but assumes the path to be relative to the current folder, which in case of the ndk-build process can be all over the place. Thus the env variable that denotes the root of the file location.
Some details here.
I have a similar issue with cross-platform codebase. I've not found any way to do this.
My workaround is to create a symlink from my source code root directory into jni, so I can give the NDK build system paths like jni/link/common/foo.c.
Just be sure that you remove the symlink if you ever need to run tools that do recursive directory traversals...

Android native project referencing shared library from c++ library project

I have 2 projects:
1 - Android Native project
2 - C/C++ Project
I'm building my shared library files (.so) in a C/C++ project and want to use those .so files in Android Native project.
I don't want to copy and paste these library files from one project to another.
First of all is it possible to use those .so files from my native Android project by using some reference etc to C++ library project?
Would it be easier to find a way to automatically copy the .so files from the C++ library project to the Android native project?
Well you'll need to re-compile your libs for ARM first. You can use the ndk's "standalone toolchain" functionality for that. There's a doc explaining more about it in the ndk dir (docs/STANDALONE-TOOLCHAIN.html). I needed to use libexpat in a project so I whipped up a bash file to compile expat using the standalone toolchain like so:
NDK_PATH=/android-ndk-r7
NDK_GCC=${NDK_PATH}/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc
export CC="${NDK_GCC} --sysroot=${NDK_PATH}/platforms/android-8/arch-arm"
export CFLAGS='-mthumb'
export LDFLAGS='-Wl,--fix-cortex-a8'
./configure --host=arm-eabi
make
Then you can copy the so wherever you want and reference it from Android.mk:
LOCAL_LDLIBS := \
-Lvendor/expat/sdk/lib/android \
-lexpat
Note that I built expat and linked it statically so I didn't have to worry about copying the resulting so

Categories

Resources