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.
Related
I am currently trying to debug native code in Android via ndk-gdb but I am having some troubles.
Even if I start a very simple project (let's say for example a default cocos2d-x v3 project) and run
ndk-build NDK_DEBUG=1
I end up with the following folder structure inside my android project
...
libs/
armeabi/
libcocos2dcpp.so
...
instead of the expected:
...
libs/
armeabi/
gdb.setup
gdbserver
libcocos2dcpp.so
...
In order to use ndk-gdb I need those two gdb files.
I am using cocos version 3.2 and Android NDK version r9d.
Isn't NDK_DEBUG=1enough for the gdb files to be generated? I have also tried withandroid:debuggable="true" inside my manifest file but it didn't work.
Edit
After running the command suggested by Digit I found a very suspicious line
Android NDK: Application 'local' forced *not* debuggable through NDK_DEBUG
when running the command ndk-build NDK_LOG=1 NDK_DEBUG=1
BUT
if I change to ndk-build NDK_LOG=1 NDK_DEBUG=true I get
Android NDK: Application 'local' forced debuggable through NDK_DEBUG
So it is ok now, really weird though how =1 is not considered true.
Can you paste the output of 'ndk-build NDK_LOG=1 NDK_DEBUG=1', this should contain more information about what ndk-build is doing, and is likely to provide an explanation.
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.
I have a similar question to that posted here:
Android NDK: why ndk-build doesn't generate .so file and a new libs folder in Eclipse?
...though I am running Windows 7, not Mac os. Essentially the ndk-build command is run, gives no error but doesn't create an .so file (also, since I'm on windows this should create a .dll and not an .so?). I tried running the command from the root, jni, src folders etc. but got the same result; cmd just returns to the prompter after a few seconds. I ran it again from the jni folder with NDK_LOG=1 parameter to see what was happening. Here is a portion of the transcript of the log results after running ndk-build in the jni folder (after it successfully identified the platform, etc.)...
Android NDK: Looking for jni/Android.mk in /workspace/NdkFooActivity/jni
Android NDK: Looking for jni/Android.mk in /workspace/NdkFooActivity
Android NDK: Found it !
Android NDK: Found project path: /workspace/NdkFooActivity
Android NDK: Ouput path: /workspace/NdkFooActivity/obj
Android NDK: Parsing /cygdrive/c/android-ndk-r8/build/core/default-application.mk
Android NDK: Found APP_PLATFORM=android-15 in /workspace/NdkFooActivity/project.properties
Android NDK: Application local targets unknown platform 'android-15'
Android NDK: Switching to android-14
Android NDK: Using build script /workspace/NdkFooActivity/jni/Android.mk
Android NDK: Application 'local' is not debuggable
Android NDK: Selecting release optimization mode (app is not debuggable)
Android NDK: Adding import directory: /cygdrive/c/android-ndk-r8/sources
Android NDK: Building application 'local' for ABI 'armeabi'
Android NDK: Using target toolchain 'arm-linux-androideabi-4.4.3' for 'armeabi' ABI
Android NDK: Looking for imported module with tag 'cxx-stl/system'
Android NDK: Probing /cygdrive/c/android-ndk-r8/sources/cxx-stl/system/Android.mk
Android NDK: Found in /cygdrive/c/android-ndk-r8/sources/cxx-stl/system
Android NDK: Cygwin dependency file conversion script:
...after which point it just runs the script mentioned in the last line, then terminates. Any ideas? Thanks!
Set up a builder. Refer to following article for how to do that:
http://maxters.net/2011/02/android-ndk-builder-for-eclipse-in-windows/
There is a "small" change beginning NDK r8 – Cygwin is not necessary anymore and I had a trouble when building native libraries with Cygwin and NDK r8 – there was some error message about cxx-stl...
Almost everything in the link above is OK, but leave Arguments in the Main tab blank and change Location to:
${env_var:ANDROID_NDK_ROOT}/ndk-build.cmd
I use system variable path ANDROID_NDK_ROOT, but you can provide a full path to the ndk-build.cmd.
Also, there is no need to set any variable in the Environment tab.
Set up your builder this way and you will be fine.
Just a note, Android is built on the top of the Linux OS, so even if you are on Windows you will get Linux libraries with .so extension.
Following link was instructive but missing a detail if you are configuring NDK support in Eclipse after CDT it already depricated (summer of 2017 already).
http://maxters.net/2011/02/android-ndk-builder-for-eclipse-in-windows/
Where you need to configure your external builder Location, instead of pointing to cygwin\bin\bash.exe and adding as Argument your ndk-build.cmd location this is what worked for me on Windows 7 and 10.
In "Edit Configuration" dialog for external builder do following:
- for Location -> specify where your "ndk-build.cmd" is. i.e "D:\Android\NDK\ndk-build.cmd"
- for Arguments -> just specify "all"
The NDK build system relies on wildcards to find the sources to compile. If you have a path wrong somewhere, it will find no sources and do nothing. Check Android.mk very carefully. More can't be said unless you post Android.mk and a description of the source tree.
I have a really simple helloworld.cpp program
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
And I'm trying to compile it for android x86 with the cross-compiler from the toolchain:
/Users/me/android-ndk-r8/toolchains/x86-4.4.3/prebuilt/darwin-x86/bin/i686-android-linux-g++ helloworld.cpp -L "/Users/me/android-ndk-r8/sources/cxx-stl/stlport/libs/x86/" -lstlport_static
However, I get errors:
helloworld.cpp:2:20: error: iostream: No such file or directory
Any idea why?
Check the documentation.html file included with the NDK, under "Standalone Toolchain". It says that if you invoke the compiler in this way you won't be able to "use any C++ STL". However it is possible, as the documentation explains, if you first create a "customized" toolchain installation, using something like the following command:
$NDK/build/tools/make-standalone-toolchain.sh --platform=android-8 --install-dir=/tmp/my-android-toolchain --arch=x86
where $NDK is the path to your NDK directory. Note the --arch=x86 which means that the toolchain is prepared specifically for the x86 Android. This prepares what you need in one directory, including the STL headers and folders. You should then be able to use -lstdc++ to link against the STL (static version), i.e. something like:
/tmp/my-android-toolchain/bin/i686-android-linux-g++ helloworld.cpp -lstdc++
For a more complete explanation, please see the NDK documentation.
The NDK documentation is not entirely accurate, at least not currently. In fact, it states when using the prebuilt toolchain "You won't be able to use any C++ STL (either STLport or the GNU libstdc++) with it.", but this is out of date. I created a small hello world program using the include with the same error. It can be solved without creating your own toolchain though, which is nice if you don't want to have to add one more step to your configuration process and allows you to always use the latest SDK platform without creating a new toolchain every time.
The NDK ships with the source code for several versions of standard C++ libraries: GAbi++, STLport, and GNU STL. Each flavor comes with prebuilt shared and static libs as well. My example below will use stlport.
To use the stand-alone toolchain at its installed location, you can do something like this:
export CXX='$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-g++ --sysroot="$NDK_ROOT/platforms/android-19/arch-arm"'
This, for example, would set your CXX compiler to compile ARM on the OS X system using SDK platform level 19. This much you probably already knew. Also, you would want to export your CC, CPP, LD, AR, and RANLIB if you use it. I also personally create an envar for READELF.
To add support for C++ libs, you could do something like follows:
$CXX helloworld.cpp -I$NDK_ROOT/sources/cxx-stl/stlport/stlport -L$NDK_ROOT/sources/cxx-stl/stlport/libs/armeabi -lstlport_shared
Note that this will link the libstlport_shared.so which will now be required at runtime, so you may need to add a relative path to the command above to support that, depending on your APK structure. If you want to just test this simple case, you can just run this on the emulator as follows:
adb push a.out /data
adb push $NDK_ROOT/sources/cxx-stl/stlport/libs/armeabi/libstlport_shared.so /data
adb shell
# su
# cd /data
# chmod 777 a.out
# ./a.out
To get rid of the headache of dealing with shared library paths, you can also statically link the C++ library in by changing "-lstlport_shared" to "-lstlport_static". There are some consequences of doing this, as explained in the NDK Dev Guide. The biggest issue is due to having the static library linked in multiple places, causing:
- memory allocated in one library, and freed in the other would leak or even corrupt the heap.
- exceptions raised in libfoo.so cannot be caught in libbar.so (and may simply crash the program).
- the buffering of std::cout not working properly
A useful tool is also included to see what dependencies your program has, the readelf tool.
To see what other shared libraries your program requires, you can run the following:
$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-readelf -a a.out | grep NEEDED
Other cool standard tools:
addr2line - convert a stack trace address to a line of code
nm - Displays the symbol table
objdump - displays info on an object
i call one of the functions from gnustl after it runs fine from prebuilt aosp arm-linux-androideabi-gcc --std=c++11 and after crashing error i cant get a backtrace from logs or reason, my hope is turning to crossbuilt qemu-linux-user to run host compiled i686 binary on the arm, difficulty is interacting with crosshost libs aapt from adt always crashes on any other than platform specific libs, unless kernel module packaged update is possible...
I am working on an android project that requires the cryptographic libraries that are present in the application to be FIPS certified. To my knowledge there are no FIPS validated JAVA security libraries. Boucy Castle is good but its not validated. After reading some forum posts, I found out that OpenSSL's FIPS module can be used with the help of NDK.
Right now I am trying to build the fips-openssl module for Android, to do that I have created a script for the environment variables for cross compiling.
I am using openssl-fips, and ndk-r8 for this project. I followed the fips guideline I found on google. I hope this gives a clear picture of what I am trying to do.
#! /bin/sh
export ANDROID_NDK="~/Android/android-ndk-r8"
export FIPS_SIG="${ANDROID_NDK}/incore"
export GCC_C1="/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/"
export PATH=$PATH:"${ANDROID_NDK}/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin";
export MACHINE=armv71
export ARCH=arm.
export CROSS_COMPILE="arm-linux-androideabi-"
export SYSTEM=android
#export RELEASE=2.6.32.GMU
export ANDROID_DEV="$ANDROID_NDK/platforms/android-14/arch-arm/usr"
export HOSTCC=/usr/bin/gcc
when doing the make this is the error that i get.
arm-linux-androideabi-gcc: error trying to exec 'cc1': execvp: No such file or directory
make[1]: *** [cryptlib.o] Error 1
make[1]: Leaving directory `/home/abhiram/fips/openssl-fips-1.2.3/crypto'
make: *** [build_crypto] Error 1
When i do a "find", the cc1 executable is present in this specific directory.
find . -name cc1
./toolchains/mipsel-linux-android-4.4.3/prebuilt/linux-x86/libexec/gcc/mipsel-linux-android/4.4.3/cc1
./toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/libexec/gcc/arm-linux-androideabi/4.4.3/cc1
./toolchains/x86-4.4.3/prebuilt/linux-x86/libexec/gcc/i686-android-linux/4.4.3/cc1
Looks like the problem is in the export statement, there is a blank space where a dash should be in the PATH line. Change this:
export PATH=$PATH:"${ANDROID_NDK}/toolchains/arm-linux-androideabi 4.4.3/prebuilt/linux-x86/bin";
to this:
export PATH=$PATH:"${ANDROID_NDK}/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin";
Also, your find shows that the cc1 executable is not in the path, so add its location to the path export as well:
export PATH=$PATH:"${ANDROID_NDK}/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin":"${ANDROID_NDK}/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/libexec/gcc/arm-linux-androideabi/4.4.3/";
Right now I am trying to build the fips-openssl module for Android, to do that I have created a script for the environment variables for cross compiling.
OpenSSL provides a script for Android, if you are interested. You can find it on the OpenSSL wiki: FIPS Library and Android.
when doing the make this is the error that i get:
arm-linux-androideabi-gcc: error trying to exec 'cc1'
It looks like your PATH does not include the cross-compile toolchain.
How are you invoking the script? You need to include a leading dot (".") to ensure the changes are applied to the current shell (and not the sub-shell that executes the script (which simply exits)).
Here' the first step of OpenSSL's build procedures for Android located at FIPS Library and Android. Notice the leading dot:
$ . .setenv-android.sh
The results of running the script set a bunch of variables used by the OpenSSL build system:
$ . ./setenv-android.sh
ANDROID_NDK_ROOT: /opt/android-ndk-r9
ANDROID_EABI: arm-linux-androideabi-4.6
ANDROID_API: android-14
ANDROID_SYSROOT: /opt/android-ndk-r9/platforms/android-14/arch-arm
ANDROID_TOOLCHAIN: /opt/android-ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/darwin-x86_64/bin
FIPS_SIG:
CROSS_COMPILE: arm-linux-androideabi-
ANDROID_DEV: /opt/android-ndk-r9/platforms/android-14/arch-arm/usr
"${ANDROID_NDK}/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/libexec/gcc/arm-linux-androideabi/4.4.3/"
I don't believe this is needed.
export ANDROID_NDK="~/Android/android-ndk-r8"
According to the folks on the Android NDK user list, you should set both ANDROID_NDK_ROOT and ANDROID_SDK_ROOT. The various NDK and SDK tools use those environmental variables. I suppose the SDK value would be "~/Android/android-sdk" for your installation.
See Recommended NDK Directory? for details.
I also think you should be using ANDROID_SYSROOT. Its not used by the NDK or SDK tools; rather, its used by OpenSSL and passed as sysroot during compile.