When using a normal build system like Makefiles, issuing make install will, for most open source libs out there, produce two directories in the --prefix=: lib/ and include/.
ndk-build -h is not helpful, neither is the android developers page. I've seen somewhere that specifying
ndk-build NDK_LIBS_OUT=/my/path/to/lib
provides the desired lib directory with the .sos in it.
Is there an equivalent for the includes?
(Specifically, i'm trying to compile SDL_ttf for android but it needs SDL.h, whereas the SDL build only provides the libs.)
Related
I have a Java Library project in my AOSP build which creates a jar file and hosts it in system/framework
Everything works as expected, however I now wish to create a JAR file from the same library to allow and application to link and compile against it. Goal is to be able to create APKs against this lib (compileOnly) so that the APK can run and use the library on the ROM.
The problem is that Jack seems to be generating only dexed jar files which cannot be used in Android Studio as libraries.
Is there a way to disable DEXing in the Android.mk ?
I know there is an option in Android.bp (cannot recall it) which gives the option for the build to generate normal jar (with .class files).
Note: I cannot use BUILD_DROIDDOC with stubs due to enviroment issues (custom ROM) assuming BUILD_DROIDDOC is only executed with lunch sdk-eng
This is for a custom ROM with Android 8.1 base. I think the custom option of not dexing in Android.dp file is not supported in this version anyway.
Anytime I clear build folder in flutter (either with flutter clean or manually), my jni folder rebuilds (~40 mins). Is that possible to compile library to some binary, and use it from android without breaking any interfaces and functionality?
P.S. My library consists of many folders and contains .mk, .c, .cpp, .h files.
Is that possible to compile library to some binary, and use it from android without breaking any interfaces and functionality?
Of course yes. Build you libraries like shared .so or static .a and use them like prebuilts. Here the example how to use native prebuilt libraries: How to link .a to .so and create new .so for android
Moreover, you can also put them together with the used SDK, NDK, AS, and other thirdparties in Docker image and work with your project from Docker.
For a project, I am using Android gradle scripts with CMake, gradle plugin is version 3:0:0, CMake version 3.6. Both gradle and CMake files are pretty simple and uninteresting (just defining the files used - I can still copy-paste them as required).
I have the following project structure; basically a codebase producing a few tens of .so files (the native part for the Android packages that get packaged into an apk, thereby called 'Executables'), which all depend on the same shared library code (static libraries, thereby called 'Libraries'). The Library code is still (relatively) volatile, so I wish the Executables to have project-level dependencies on them, so that whenever the Executables are built, the Libraries are rebuilt on-demand every time their code is changed.
The structure looks like:
+ LibProjects/
---Bin/ (Originally empty)
---Lib1/CMakeLists.txt (+sources files, same level as the CMakeLists.txt)
...
---Lib10/CMakeLists.txt (same)
+ Executables/
---Executable1/CMakeLists.txt (source files here)
--------------/AndroidFiles/build.gradle (and other android project files)(points to the CMakeLists.txt)
...
---Executable40/CMakeLists.txt
The Libraries' CMakeLists redirect their output into the Bin folder using
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY {CMAKE_CURRENT_SOURCE_DIR}/../Bin/${ANDROID_ABI}/${LibraryName})
The executable's projects add dependencies on the libraries "as normal"
add_subdirectory(${PROJECTS_ROOT}/LibProjects/${LibraryName} ${PROJECTS_ROOT}/Framework/Bin/Android/${ANDROID_ABI}/${LibraryName})...
Everything almost works, in the sense that I can get sensible executables and the Executables trigger builds of the libraries.
The problem is that when building the executables sequentially, each one does NOT reuse the library project outputs of the other ones: When I build Executable1, it will build all libraries (normal) and then it will build itself. Afterwards, when I build Executable2, it will NOT reuse the libraries that were already built for Executable1, and so on - this effectively increases my build time by a factor of ~10.
I can find the output of the build of each library inside the /Bin folder as expected, but they are not reused across executables - there are no CMake "project files" (is this the correct term) in the bin folder, all of them get generated inside the executable build directory.
The problem I am trying to resolve is the build times stemming from the fact that each library gets rebuilt for each executable.
At the moment the solutions I am considering is to somehow instruct CMake to use the Bin folder (or another folder) as a working folder for each library in its own folder instead of with the executable, hoping that the gradle android plugin will be smart enough to then spot that neither the cmakefiles nor the object files need to be regenerated, and avoid the rebuild.
The restriction that I have is that I cannot restructure the codebase itself, and that each Executable must be buildable separately of the others - there is absolutely no possibility of a top-level CMake - each Executable should be able to be triggered on its own.
CMake can guess if the build is up-to-date by reading informations froms the current build directory.
When you run CMake manualy in Executables/<x> directory, cmake retrieve information from the build directory associated to Executable/<x> directory. It then check if the timestamp of the built file correspond to the last build performed in this build directory. If not, it rebuild. What happen is that: Lib1 library file is built after you build Executable1, then you run cmake in Executalbe2, it compares the timestamp of Lib1 target file, see that this file was not produced by this instance of the cmake build and then rebuild the lib. And so on.
So you have two options:
1- Either you build the library and install their target files in the bindirectory (using install cmake command and make install bash command for exemple). Then in the Executalbe<x>/CMakeLists you use find_library command instead of add_subdirectory.
2- Or you create a super project which has the following structure:
+ supper_project
---CMakeLists.txt #add_subdirectory(LibProjects/lib<x>)... add_subdirectory(Executables/Executalbe<x>)...
+ LibProjects/
---Bin/ (Originally empty)
---Lib1/CMakeLists.txt (+sources files, same level as the CMakeLists.txt)
...
---Lib10/CMakeLists.txt (same)
+ Executables/
---Executable1/CMakeLists.txt (source files here)
--------------/AndroidFiles/build.gradle (and other android project files)
(not any more:points to the CMakeLists.txt)
...
---Executable40/CMakeLists.txt
I managed to work around this problem - but in the end it was by working around rather than with CMake.
I removed the CMakeFile-level dependencies (add_subdirectory) and only left the libraries at the linking level (target_link_libraries Executable [the library files])
Afterwards, I created gradle scripts for each library and added dependencies to these scripts in each application gradle script, so that the building of the libraries gets triggered by gradle dependencies instead of CMake dependencies. It's slower than it would be if gradle could be avoided, but much faster than rebuilding every time, and the overhead is at least constant (a few seconds per project).
I think problem lies in the way you have defined your dependencies.
For each executable you are creating separate targets using add_subdirectory.
e.g. for executable 1 you have add_subdirectory(${PROJECTS_ROOT}/LibProjects/${Library1}) and for executable 2 also you have add_subdirectory(${PROJECTS_ROOT}/LibProjects/${Library1}), so cmake will create two separate targets for same library1 in each of the executable's subdirectory and thus it will create separate timestamp and cache files. That is why it looks that it is building the same library for multiple times, but in fact for cmake they are different targets.
To fix this you can include all libraries in top level CMakeLists.txt using add_subdirectory and them in each executable's CMakeLists.txt add the dependency using add_dependencies command.
I've been doing a lot of attempts to get libpcap compiled for Android, and I don't see any pattern or any progress worth writing down.
I have a very simple sniffer (that works fine in a MIPS linux) that uses libpcap, so I thought to myself oh, ok... no biggie... I'll just compile libpcap for Android (in the end, Android is just a Linux)... and here's where the problems started. I have no idea on how to compile libpcap using ndk-build and the Android.mk and all that infrastructure.
I have the Android NDK in a directory. That NDK has the toolchains built (I have a lot of directories under ~/Documents/Projects/Android_NDK/toolchains/ ) but none of the toolchains has libpcap available.
I've tried with two different libpcap version or... branches:
The Android one, which is the one I'd like to use,
https://android.googlesource.com/platform/external/libpcap/
and the regular one:
http://www.tcpdump.org/release/libpcap-1.5.3.tar.gz
All tries I've done have been very unsuccessful. I've seen the question Android NDK: Link using a pre-compiled static library which is similar, but I'm still getting various errors.
I have downloaded those pcap libraries to their own directories. Maybe is that the problem? Do I need to put the Android libpcap in some directory within the NDK root directory and re-create the toolchains?
I'm using NDK-r9 on a MacOSX 10.9.2 64bit.
Finally!!
After getting annoyed by the non existing headers in and stuff like that, I found this question, that pointed to a SVN repo (http://sourceforge.net/p/prueba-android/code/HEAD/tree/trunk/jni/) with a libpcap that compiled!
If someone else wants additional details on how my Android.mk and directory structure looks like, please add a comment and I'll extend this answer.
Please read an excellent article at http://blog.umitproject.org/2011/05/libpcap-for-android.html. There are instructions that will help you link to libpcap, but the most important takeaway is that you cannot use libpcap on non-rooted Android. So maybe it's not worth your effort.
On a rooted device, you can simply install a free sniffer like Shark for Root.
If anyone else is having problems compiling libpcap for Android using the NDK, there is version 1.5.2 here with a built Android.mk file in it: https://android.googlesource.com/platform/external/libpcap.git and instructions for compiling this using the NDK are here: http://ducbh.blogspot.co.uk/2013/12/cross-compile-libpcap-for-android.html . I can confirm this works using the current NDK (r10b)...although you may have to add AndroidManifest.xml (blank) and and Application.mk that points to your Android.mk file.
I don't think it would be that difficult to modify the .mk file for the current libpcap version (1.6.2)
In case anyone ends up here in 2022+. You can now cross-compile for Android from the official source. Steps:
First, setup the NDK:
Download Android NDK (I used r21e) and extract to a directory of your choosing:
$ cd ~
$ mkdir Android
$ unzip android-ndk-r21e-linux-x86_64.zip
Prepare the environment variables for cross-compilation by placing the commands below (replace <YOUR_USER>) into a file named setup_env.sh (can be saved anywhere):
export NDK=/home/<YOUR_USER>/Android/android-ndk-r21e
export TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/linux-x86_64
export TARGET=aarch64-linux-android
export API=21
export AR=$TOOLCHAIN/bin/$TARGET-ar
export AS=$TOOLCHAIN/bin/$TARGET-as
export CC=$TOOLCHAIN/bin/$TARGET$API-clang
export CXX=$TOOLCHAIN/bin/$TARGET$API-clang++
export LD=$TOOLCHAIN/bin/$TARGET-ld
export RANLIB=$TOOLCHAIN/bin/$TARGET-ranlib
export STRIP=$TOOLCHAIN/bin/$TARGET-strip
Now, build libpcap:
Download libpcap tar ball (e.g. https://www.tcpdump.org/release/libpcap-1.10.1.tar.gz)
Extract (in a directory of your choosing): tar xf libpcap-1.10.1.tar.gz
Prepare your env: source <path_to>/setup_env.sh
Change into the extract libpcap directory and configure: ./configure --host=aarch64-linux-android
I found the Makefile generated had the wrong linker set (line 48), so I had to change it to: LD = /home/<YOUR_USER>/Android/android-ndk-r21e/toolchains/llvm/prebuilt/linux-x86_64/x86_64-linux-android/bin/ld
Finally, build: make
This build worked for me with running tcpreplay on a rooted Android, hopefully it works for other purposes as well!
I'm porting a modem connection manager written in C++ from linux to gingerbread. This does not end up being an "app" with a "gui" that I would use a java wrapper with the NDK but a service that is called at boot from "init.rc". I found some not up to date docs related to android build system under build/core/. There you find some html files explaining the basics of Android build system and several "file.mk" which are some templates for common situation like creating a c++ executable, static libraries, shared library etc.
I place my tree with all the sources under external/myservice and it's meant to be compiled at the same time as Android itself. (I've already ported the kernel to my platform and it works, just the modem left to go)
In a subfolder in an Android.mk file, I have a bunch of ".cpp" files listed with the variable LOCAL_SRC_FILES := cppfile1.cpp cppfile2.cpp .... That will generate cppfile1.o cppfile2.o ...
I need to link those cppfile*.o with objfile.o to form a libfile.so. I found the rules on how to generate a libfile.so from a bunch of files.o.
Where things get complicated, is to port the "linux makefile" command to create objfile.o. Here is how it looks like
$(LD) $(LDFLAGS) -r -b binary -o QMIDB.o \
QMI/Entity.txt \
QMI/EnumEntry.txt \
QMI/Enum.txt \
QMI/Field.txt \
QMI/Struct.txt
Which means it is a linker job to merge a bunch of text file to make that objfile.o. That file is just a bunch of initialized data structure, there is no code to execute in it but it's pretty ugly to look at all files.txt with a text editor.
I have no clue how to integrate that in the Android.mk file. How can it be done? I'd even appreciate just a hint on where I can find more information. It is easy to find information on building Android applications but it's another story to find anything closer to Android/Kernel itself.
From the mk. file file you can easily get so file....
You need to use android Ndk setup and cygwin setup if you are using windows platform to genreate so file from your native code.
Firstly install and place ndk to a location...
Then install cygwin setup not default one check all features in the installation process (it a sort of linux terminal) as ndk-build command is recognized from linux terminal.
Now from your cygwin terminal get access to your project folder jni file.. or where mk is placed...
http://developer.android.com/sdk/ndk/index.html
Use the following referal how to run ndk-build command from cygwin terminal..
Now providing complete path of ndk we use the ndk-build command...
After that the complied code generates the .so file for our project...
Now what we are using System.loadlibrary command to use the so file i.e our native code can now be used.
Note to get so file form mk we need to complie using ndk setup.We can't directly copy paste so file to make our native code run.Also we we are using windows platfrom we will need to use cygwin setup to do that