Is there a way to port Snort to Android OS? I have already ported
libpcap to Android and I have made some simple native sniffers which worked
perfectly.To do this, I used the NDK development kit that offers you some
tools for cross compiling C programs to ARM architecture.
Is this possible to do it for Snort. I know that Snort is a big project that
contains many source files and uses many modules such as Libpcap, PCRE,
Libdnet, Barnyard2, DAQ. I am wondering if is there a way to build
this code for Android.. E.g. by statically link all this modules.. Moreover an
other potential problem may be the fact that Android uses a subset of libc
(bionic), so maybe some basic functions are not available..
Have anyone done it before? Or, can some one give me some help on how
to start?
Lack of exception handling and STL was very painful when i ported using NDK. As snort is C based, that shouldn't be the case. I guess unicode handling (as ndk doesnt support wide char functionality) can get tricky.
Related
In our team we have a C++ project built on OpenCV and VLFeat written by a colleague who has just left.
I have been asked to cross-compile it for Nexus 4 (ARM), run it and profile it (gprof).
Hence, it is not necessary to pass through the Java wrappers and the NDK: no app is requested.
I am having big troubles with that because I am a complete novice in crosscompilation: all the guides and tutorial I find advice to use the NDK. For example, this book very nicely explain how to setup the whole system (using the NVIDIA Tegra development kit that bundles the Android SDK, NDK, Eclipse and OpenCV)
Do you think that crosscompiling such a big project with so many dependencies on arm it is a viable option? I am also concerned that, even in the case in which I will manage to cross-compile, the code won't work.
If yes, can you kindly point me to some resources which explain me how to do it (besides the OpenCV instructions, which have been not particularly useful)?
If no, I would really appreciate if somebody with more experience than me in the argument could debate the reasons why it is much better to use the NDK.
------------- EDIT ------------
For sake of completeness, I report my progresses.
I managed to cross-compile OpenCV for ARM, generating static libraries. I have also successfully crosscompiled VLFeat.
Now, it happens what I was afraid of: make throws up a huge list of undefined references. I have pasted the head of the &> output in this pastebin.
Any consideration? I am almost seriously convinced that a rough cross-compiling will never work, and it is better to re-do the entire project passing from the NDK. Obviously, I hope that somebody could contradict me.
Thanks in advance for your help, I do not know which way to turn.
You can just use NDK compilers and regular makefiles without using the NDKs build scripts. There is script that makes NDK compiler behave more like a regular GCC right here https://code.google.com/p/android-cruft/. The script was last updated 4 years ago, so it might need further facelift.
The biggest problem you might face is incompatibility in the C library or missing support for advanced C++ features. The Android is somewhat Frankenstein system, it uses linux as a kernel, but BSD like C library. Many low level utilities do not compile well for such environment. Also, a lot of C++ features depend on libg++ library which might have strong tie-ins into GNU C library.
I had a look at your pastebin. The first thing that stands out is libjpeg, or lack thereof. I don't know how your link step did not involve -ljpeg. You also need some pthread - related stuff. Note that Android supports almost all pthread APIs, including pthread_mutex_init(), but does not have libpthread; instead, all these functions are defined in libc. Maybe, other libraries are missing, too.
We're building a big app, including OpenCV, boost, libjpeg-turbo... For all this we use CMake to generate Makefiles that use the NDK.
Looking at your linking errors, it seems you're missing some libraries in your link command line. -ljpeg probably. For pthread, I'll have a look at how we handle it at work.
I wrote a library in latest Linux distribution, which depends on glibc and sockets. I hear that glibc is not supported in Android. Is there a way that I rebuild my code without much modification for Android and let it run? If yes, I will use JNI to call the code.
No, that's not possible. Android runs with bionic, and doesn't have glibc.
However you can try to build your code with NDK and fix the problems on the way to build it.
If you don't use anything glibc specific, it should be fairly easy.
It depends on what you mean by "uses glibc". If it uses non-standard extensions that only glibc implements, then you'll have some trouble. But Android's libc (called "bionic") supports most of POSIX, so if you aren't doing anything too unusual, it should work. The best way to find out is to try to build your library with the NDK and see what happens.
We want to migrate a huge complex native program to Android system ,running it as a background service accepting command sent from Java Program using JNI along with IPC. However, the Android NDK state following words:
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Does that mean we have no way to run an standalone native-only application on Android as a background service? The native code can only exist in the form of library that will be loaded to the virtual machine through JNI?
The NDK itself is only for creating libraries, though if you do some web searching you will find that there are at least two sets of wrapper scripts or instructions for (ab)using its toolchain to make standalone executables linked against android's bionic libc (something you would not get from a non-android arm toolchain).
The google folks do not encourage people to do this. Unfortunately, their vision of android only includes java applications, with optional native libraries in support - it does not include any "stable" means of installing or launching a native executable, in the sense that they warn the methods you might be able to use today may not continue to work in new versions. This is really too bad, as it means giving up a lot of the general-purpose-computer potential of the device.
Well, it can be done. But to be honest i've never tried it using the NDK, but i've managed to create native applications using the toolchains provided with the android source code.
Your phone (incase your talking about phones) should be rooted.
Since Objective-C exists and is supported even in MinGW, by passing -x objective-c, is there a hack to achieve this with Android SDK? I've did a rudimentary test on a colleague's machine where it appears that language objective-cis not supported.
I am not interested in getting UIKit or AppKit, or even Foundation, to work; I've written most of an OpenGLES game in Objective-C, and successfully ported it to Mac OS X and Windows; I am fairly certain I could easily port it to GNU/Linux once I get time to figure out enough of GNUStep (and even without it, I could create the classes to get the game running).
I'm just interested in the base language and basic runtime (including properties, if possible); even NSObject can be easily written to the extent I need it.
In the meantime, I've managed to compile some Objective-C code, and have written a guide for this:
Developing Objective-C apps for Android using Mac OS X
There are more details in my answer below.
The Apportable platform includes a Clang compiler integration with the Android NDK. It also includes a bunch of other useful features if you want to go beyond basic Objective-C language and runtime support.
You probably have to recompile the ndk gcc's sources with that option enabled. At the extreme you might have to find the code for that option upstream and add it to the ndk gcc's sources.
Porting runtime libraries to work on top of bionic instead of glibc may be more interesting.
Note that android doesn't really handle pure-native binaries very well, you will need to either be called as a jni library from a java wrapper application which you will have to call back up through for audio or forked and exec'd off of one (not recommended, and leaving you with device-dependent hacks for audio).
There is this Google Code project: http://code.google.com/p/android-gcc-objc2-0/ however I have not tested it yet.
Also, I have inquired on the Cocotron mailing list whether or not this compiler is usable with Cocotron's Foundation and CoreFoundation; one person responded that it is not, and that he has worked on the problem: http://groups.google.com/group/cocotron-dev/browse_thread/thread/448355f2a6c9c28e#
In the meantime, I've managed to compile some Objective-C code, and have written a guide for this:
* Developing Objective-C apps for Android using Mac OS X
Clang is included in NDK nowadays if that's all you need.
Has anyone used the Android NDK to port a Linux app? We have an SSL VPN solution at work which Openconnect (http://www.infradead.org/openconnect.html) works with, but there is currently no client (from Cisco or otherwise) on Android. Is using the Android NDK a feasible approach to get this to work?
Thank you in advance
The NDK is a good solution for porting C/C++ Apps. You need to do a thin java shell to pass over any input, init and exit the program.
If your C app requires STL or exceptions - there are modified versions of the NDK that support them.
The Android NDK is not for porting apps. It is for creating libraries that can be accessed from a standard Android Dalvik app via JNI.
So, if you have the source code to this project, and it results in a .so, and you can write a JNI wrapper for it, the NDK may be a solution for you. Considering the project you cite seems dependent upon scripts, I suspect that's not how it was set up for use.