I'm using the Native Development Kit (NDK) in a project of mine, and I'm trying to automate the whole app build procedure with Python.
Whenever ndk-build is called, it copies the prebuilt shared libraries to libs/<abi>/, even if there's no changes in them or they already exist there. This causes problem when I call ant later on, as it detects changed files (the library timestamps are newer) and so rebuilds the apk without any need.
Is there a way to change the ndk-build behaviour so it checks for existing libraries in the libs/<abi>/ folder and if they need updating or some are missing, it will call ndk-build, otherwise, just proceed to the next build step?
I've tried using filecmp in Python, but as the timestamps are different between the prebuilt shared libraries and the installed ones, it doesn't work.
The OP probably doesn't need this any more, but I had the exact same problem, trying to set up a Makefile to build a project, so maybe this will be helpful to someone else in the future as well.
ndk-build is a wrapper around gnu make, that invokes a bunch of Makefiles in build/core directory of the ndk, so, while it's not universally applicable*, for your personal project you can modify those Makefiles to do whatever you want. I found a clean-installed-binaries target that a couple of build/install targets depended on, removing those dependencies fixed the issue with perpetual installs.
In whichever cases that clean target is necessary you can invoke it manually with:
ndk-build clean-installed-binaries.
*Given the time to come up with a clean opt-in solution you can submit a patch to ndk project, and if accepted it will eventually become universally applicable.
NOTE: it apparently is a recurrent question on StackOverflow, but - for what I have seen - either people never find a way or their solution does not work for me
The problem:
I am using Eclipse Juno ADT. Everything was working fine until I tried to update the NDK. I replaced my ndk folder (that was the ndk-r8d) by the new version (i.e. ndk-r8e) and, in my Paths and Symbols configuration, I changed the includes to go from g++ 4.6 to 4.7.
It seemed to break my index: I could compile my code, but Eclipse was giving semantic errors, exactly like in [1] and [2]. The errors mainly come from symbol used by OpenCV4Android, such as distance, pt, queryIdx and trainIdx.
When I tried to backup to my old configuration, the index was still broken! I cannot find a way to change this.
What I have tried
Clean up the project
Rebuild, refresh, and all the other options in the "Index" submenu (when "right-clicking" on the project)
Disable / enable the indexer in the preferences
Verify that symbols such as trainIdx only appear in my OpenCV4Android include in the Paths and Symbols section.
Change the order of my includes in the Paths and Symbols section. I basically tried to put the OpenCV include in the beginning and in the end.
Some observations
What is not working
I assume that it is the CDT index because of the following:
In command line, I can build my project using ndk-build clean and ndk-build.
When I start Eclipse, I have no error until I open a C++ file (from the jni folder).
I can always build the project, but as long as I have opened a C++ file, I can't run the application anymore because of a lot of Field '<name>' could not be resolved.
If I don't open the C++ files, Eclipse doesn't report any error and can build and deploy the Android application successfully.
Interesting fact
The following code reports errors on line, queryIdx, pt:
cv::line(mRgb, keypointsA[matches[i].queryIdx].pt, keypointsB[matches[i].trainIdx].pt, cv::Scalar(255, 0, 0, 255), 1, 8, 0);
If I write it as follows, it works:
cv::DMatch tmpMatch = matches[i];
cv::KeyPoint queryKp = keypointsA[tmpMatch.queryIdx];
cv::KeyPoint trainKp = keypointsB[tmpMatch.trainIdx];
cv::line(mRgb, queryKp.pt, trainKp.pt, cv::Scalar(255, 0, 0, 255), 1, 8, 0);
It is not that all of the OpenCV functions are unresolved: only pt, queryIdx and trainIdx are.
Any comment will be really appreciated.
In your selected project preferences within the Eclipse environment, go to C/C++ General -> Code Analysis -> Launching. Make sure that both check boxes are unchecked. Close and reopen the project or restart eclipse and rebuild the project.
Since indexing for Android native code on Eclipse is incomplete, I managed to enable indexing in my NDK projects the following unintuitive way, it should work whether you use ndk-build or plain make or even cmake. I'm using Kepler but it should work on older versions too.
Get your toolchain right
Right click on project -> Properties -> C/C++ Build -> Tool Chain Editor -> Uncheck Display compatible toolchains only.
In the same window, set Current toolchain to Linux GCC.
In the same window, set Current builder to Android Builder if you're using ndk-build, set it to Gnu Make Builder otherwise (this step may be wrong, sorry in advance if it is).
Right click on project -> Properties -> C/C++ Build -> Build Variables -> Make sure Build command reads the correct command for your project; if it's not, uncheck Use default build command and correct it (it may be ndk-build or make -j5 that you want). If you build the native code in a separate terminal, you can skip this step.
Make a standalone toolchain, it's probably the cleanest way to get STL sources in one place
Go to the NDK root directory.
Run the following (tweak the settings according to your liking). Add sudo if you don't have write permissions to the --install-dir because the script fails silently.
./build/tools/make-standalone-toolchain.sh \
--platform=android-14 \
--install-dir=/opt/android-toolchain \
--toolchain=arm-linux-androideabi-4.8
This is assuming that you use GNU-STL. If you use another C/C++ library, you will need to tweak the above command, and probably also the include paths in the next command.
Add the necessary include paths to your project
Right click on project -> Properties -> C/C++ General -> Paths and Symbols -> Go to the Includes tab -> Select GNU C++ from Languages -> Click Add and add the following paths (assuming you installed the standalone toolchain to /opt/android-toolchain):
/opt/android-toolchain/include/
/opt/android-toolchain/include/c++/4.8/
/opt/android-toolchain/include/c++/4.8/arm-linux-androideabi/
/opt/android-toolchain/lib/gcc/arm-linux-androideabi/4.8/include/
/opt/android-toolchain/include/c++/4.8/backward/
/opt/android-toolchain/lib/gcc/arm-linux-androideabi/4.8/include-fixed/
/opt/android-toolchain/sysroot/usr/include/
Here, you can add every include path you want. In fact, I have my OpenCV built for Android and installed in the standalone toolchain, so I have the following include there:
/opt/android-toolchain/sysroot/usr/share/opencv/sdk/native/jni/include/
Now, the indexing should work. You should also be able to run ndk-build (or make if that's your build method) and then deploy your project to your device inside Eclipse.
Why?
Android native development on Eclipse is incomplete since the indexing doesn't work out of the box. This is due to having to support multiple architectures (ARMv7, Intel etc.), multiple STL options, multiple Android versions etc. This is why you have the bare make based ndk-build and the whole NDK structure, and this is also why NDK development is very unclean and few large volume native Android projects exist.
A big Android project is OpenCV where they had to develop a 1500 odd line CMake script to get it to compile for Android properly. At some point, they tried to export that script as a CMake based build system for Android but it couldn't keep up with the changes in the NDK system and was abandoned. This support should have been inside NDK itself.
The default NDK build system should have been standalone toolchain only, with all different architectures/C++ libraries having their own toolchains at the cost of storage space but with the advantage of cleanness, intuitiveness and good practice. Then you can incorporate any standard cross-compilation system that is also used elsewhere, is tested and is well-known, e.g CMake. You can, and in my opinion you should, do that with the NDK's make-standalone-toolchain command as shown above. But in the end, this is only my opinion. If you feel comfortable enough with ndk-build then go ahead.
It's actually quite hard to say what is the problem. Here are some advices:
Try to import and build hello-jni (it is located in jni's samples folder). If it runs without problems than problem is with linking OpenCV to your project.
It seems that you forgot to update android-ndk location in project properties -> c/c++ build -> environment. Here's link to problem Issue with build Android NDK project.
Build from console your project (ndk-build -B), delete all errors in Eclipse manually (in Problems view select all errors and just click delete) and try to run project now. Sometimes this "hack" helps me to run project.
Close Eclipse and delete folder path-to-your-workspace/.metadata/.plugins/org.eclipse.cdt.core (backup it first).
Go to Preferences > C/C++ > Language Mapping > ADD (Source C File and select GNU C) Do the same for C++
I had the same issue. I had all the proper include paths setup but after opening the .c/.cpp or .h file and it would start marking everything as "Unresolved."
This worked for me...
Go to:
PREFERENCES -> C/C++ -> INDEXER
Check Index Source And Header Files Open in Editor.
I had the same issue, like many people.
I followed the steps in Ayberk Özgür post, which make good sense. Although I also had to make sure to put includes under all three languages: GNU C, GNU C++, and Assembly. Probably because I'm not using a stand alone tool chain.
I at first had my includes only under GNU C and GNU C++ languages. Which left me still with the unresolved includes error. Not until I assigned my includes under the Assembler language as well did my errors go away.
I do not know why eclipse is only searching through the Assembler includes in my project. I also do not know how this part of the solution will work for bigger more complicated projects.
Hope this helps.
I had the similar situation with Eclipse CDT working with the OpenCV library. I got several error messages while the program compiled correctly. I changed the indexer setting in "window->preferences->Indexer" "build configuration for indexer" box to "Use Active Configuration" which solved my issue.
I just spent about 3h banging my head against this Eclipse NDK indexing issue!..
What made it work: make sure that you have only ONE cpu architecture specified in Your Application.mk file.
Otherwise the .metadata/.plugins/com.android.ide.eclipse.ndk/*.pathInfo file will not be generated by the NDK build. This file contains built-in values from Project -> Properties -> C/C++ General -> Paths and Symbols -> Includes (just making .pathInfo file does not fix the problem)
I've got a hold of a proprietary JNI application which I need to build for a MIPS device. I've read "Initializing a Build Environment", parts of the NDK docs, some Google Groups threads and numerous StackOverflow questions, but I'm still short of my answer.
So far, I've checked out the Android source using Google's repo script and have it under ~/AndroidSource. I've also separately downloaded the SDK under ~/AndroidSDK and the NDK under ~/AndroidNDK. The code I'm trying to build is in a separate location. The SDK and NDK binaries are in my path. For building, I tried to use two different versions of the NDK as well as the one under the Android source tree, and experienced different sets of problems. My current setup uses NDK r8b, downloaded separately from the Android source.
The application has its Android.mk and jni/Android.mk. However, several directives in the latter point to paths such as
frameworks/base/include
system/core/include
with no prefixes. I thought these were meant to point to the respective directories in the Android source, so I symlinked them to the current directory. After some more symlinking and makefile and source hacking, I got the application to compile, but am currently stuck on the linking phase with lots of references to missing method bodies. During the whole time I knew I was doing something wrong.
I'm on a Linux x86_64 host, if it is of any concern.
So my question is:
What is the proper method to set up a build environment for JNI applications? What environment variables, symlinks and/or path expansions should I set up? Do I need to call any scripts once or before each ndk-build invocation?
Also, I'd be happy if you corrected me on any concepts or terminology I've gotten wrong.
Your approach wiyh symlinking the AOSP tree for system headers is correct. What you need now are the system libraries compiled for MIPS. The easiest way to get them is to adb pull them from a target device (or emulator image). But you can also build these libraries yourself, as part of the AOSP build (see build instructions for the source tree you downloaded).
If you still have any problems remaining, run your ndk-build with parameter V=1 and publish the link command and its results.
I use the following in my build (YMMV).
Explicitly invoke arm-linux-androideabi-gcc as your compiler or linker (should be in PATH).
NDK_PLATFORM=/path/to/android-ndk-r*/platforms/android-14
Pass -I"$(NDK_PLATFORM)/arch-arm/usr/include" to the compiler
Pass -nostdlib -L"$(NDK_PLATFORM)/arch-arm/usr/lib/" -lgcc -lc -lm to the linker
Can somebody help me write Android.mk for LibXtract or point me in correct directoin?
Here is source for lib - https://github.com/jamiebullock/LibXtract.git
Or mayby there is a way to use linux generated shared objects in Android?
Especially for bigger established projects, crafting Android.mk files is quite an effort. More so, if you are not familiar with Android NDK build architecture whose understanding requires digging deep into the documentation and Android NDK make files. I would suggest trying to use existing make files by setting CC to point to your NDK tool chain, and CFLAGS += -sysroot $(SYSROOT) where SYSROOT=${NDK_INSTALL_DIR}/platforms/android-<level>/arch-<arch>/ (depending on targeted Android API version and architecture). Even without knowing about your library, I would bet you should have good chance of success this way. Android NDK documentation (${NDK_INSTALL_DIR}/doc/STANDALONE-TOOLCHAIN.html) details the use of independent tool chain and also instructs how to create a standalone tool chain that will not require the use of -sysroot argument to xxx-gcc.
If you decide to use Android.mk instead, you might check existing projects -CSipSimple comes to my mind (PJSIP converted from standard form GNU make files).
Important is to create the shared objects using Android tool chains. It is possible to build them outside of your application source tree, and then just copy the shared objects into the package source libs/<architecture>/ directory.
Integration with your build system depends on details that are not known (including how smooth you desire this whole integration to be e.g. because of other people working with the same project). If you are creating an application from command line, the easiest would be to have GNU make file or shell script in the package root directory ensure libXtract.so and your application package is up-to-date by calling libXtract make file and ant to build and pack your Java application. If you are using ant there should be a way to specify using make to take care of libXtract.so. I am not sure if eclipse is completely relying on ant for building an application to know if this would be enough for enabling complete build by clicking mouse buttons from within eclipse, too.
The answer to this question says you could use cmake script to build Android.mk files - I have not tried this approach.
This is really frustrating
- I can build my native code from command line, but when I build from eclipse(Sequoyah plug-in enabled) its simply through simple compilation errors like headers not found...
EVen when i build the library from command line everytime I try to run from eclipse it rebuuilds and there goes errors again
- I'm frustrated as I ran out of option to locate the issue
Can some one shed some light on this.
The error you are seeing is Unresolved inclusion with error markers at each header that Eclipse's editor cannot find. This is confounding when you see it, because it is expected that after installing Sequoyah and the ADT, pointing the Sequoyah configuration to your NDK, that you'd have everything you need to start coding.
Two things to observe. The process of building in the ADT "Android Perspective" will work until you click on one of your C/C++ files in your jni directory. Once you open one of these, you'll see the error marker and the project will be tagged as containing errors.
Second observation, when you convert the project to C/C++ perspective or to Sequoyah's Android Native perspective (apparently there's two ways to skin this cat), you will have the ability to configure the project settings around NDK toolchain, include paths, and builder settings. This is where you can set the ndk-build to automatically fire off on each change. And funny thing too is that the ndk-build will work fine until you click on one of your C/C++ sources.
So solution, click [here] http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.cdt.doc.user/tasks/cdt_t_proj_paths.htm and you'll get instructions for configuring the CDT's include paths. You want to set your include paths for C/C++ (either, or both) so that you get to the platform folder includes.
Example, I've got my project hello-jni-to-the-world project set to android-9. So configure the include path: android-ndk-r6b/platforms/android-9/arch-arm/usr/include . Now the magic won't show up until you click apply/save and you'll be prompted to rebuild the indexes.
There are two to three other threads on Stackoverflow asking the same question, and I'll have to find them and add them to the comments. Basically, there were no definitive answers and there's a lot of the usual answering a question with a question: which version of NDK do you have, can you post your code, did you install java, is your computer on ?