I'm specifically interested in how portable it is between various phones. We have an application with some computation heavy code we'd like to share between Android and iPhone. If we could write it in C, we'd have a single code-base, but if the NDK only supports a subset of the processors that phone manufacturers are creating, or if we have to recompile for each processor, that's not a workable solution.
Thanks for any experiences with it.
On the subject of whether all Android (version 1.5+) phones will support the output of the current NDK:
All I can say is there's nothing in the documentation to suggest otherwise (unless perhaps if you read an implication in "this release supports the ARMv5TE instruction set"), and I follow Android news fairly closely and haven't heard of any Android phones being released using a non-ARM architecture (though some people hacked together a build for EeePC). Looking at the Android source, there are traces of only one other platform, x86. As for the future plans of Google and the OHA? You'd have to ask them. They recently announced some developer days, but probably all the spots are gone now (the first one is today). I registered pretty early for the London day (17th) so if I get in I'll try to get an answer there (I'm keen to know definitively too).
I am not very familiar w/ Iphone development, but if you look on the android ndk page, under the development tools section, it lists the guaranteed headers available in the platform, so if the iphone supports these functions, or you can create interfaces between your code and the native libraries on both platforms than I don't see why it wouldn't work.
The NDK is basically an implementation of the Java Native Interface for Android. It gives you GCC 4.2.1 (the full set of tools as far as I can tell) with target arm-eabi. Whether the resulting code would run on an iPhone or other devices I don't know; I've never coded for the iPhone. Here is what file has to say about something I built with the NDK so perhaps you can compare:
libpuzzles.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
(strip is included; I just haven't run it here.) Here is gcc -v or g++ -v (they're identical):
Using built-in specs.
Target: arm-eabi
Configured with: /opt/digit/android/git/android-ndk/out/arm-eabi-4.2.1/toolchain/src/gcc-4.2.1/configure --prefix=/opt/digit/android/git/android-ndk/build/prebuilt/linux-x86/arm-eabi-4.2.1 --target=arm-eabi --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --enable-languages=c,c++ --disable-libssp --enable-threads --disable-nls --disable-libmudflap --disable-libgomp --disable-libstdc__-v3 --disable-sjlj-exceptions --disable-shared --with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-target-optspace --with-abi=aapcs --disable-nls --prefix=/opt/digit/android/git/android-ndk/build/prebuilt/linux-x86/arm-eabi-4.2.1 --with-sysroot=/opt/digit/android/git/android-ndk/build/platforms/cupcake/arch-arm --program-transform-name=s,^,arm-eabi-,
Thread model: single
gcc version 4.2.1
Assuming the code will run, managing this at the API level is a separate and interesting issue. Android will only let you call native code via the JNI API. I'm not familiar with the iPhone approach, but I know it's not Java so I'd guess it's more like standard dynamic linking or dlopen()? What I mean is, you would have to either make your JNI functions (e.g. Java_com_example_Foo_YourMethod(JNI_Env*, jobject, ...) cope with being called from something that isn't a JVM (have your iPhone code fake a JNI_Env for example?) or, much less horribly, start by providing a native API suitable for iPhone and then include a JNI wrapper, which non-JNI platforms can safely ignore, which I gather is a common approach for this sort of thing. Hope that helps.
I have had a nice experience writing cross-bread JNI/C app with framebuffer processing in NDK and rendering in JAVA.
Pitty, its an android-only solution
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.
After searching a lot and reading a lot of information, I cannot decide which tool I should use for compiling my code. My codebase is mainly c++. I use primarily linux as my development machine.
Based on opinions I read before, my final candidates are waf and cmake, but I cannot decide myself which one should be more appropiate.
My primary requirements are:
Must be able to compile software in windows/linux and android.
Must be ready to run tests.
Must be able to play nicely with other libraries that must be compiled with another build system but most likely will have to be compiled from source.
Must be able to add custom steps, like for example, generating some data from some files (mainly graphics) before compiling, all integrated in the build system.
Some strong preferences are:
Being ready to support MAC compilation.
Being able to cross-compile from linux as many platforms as I can (maybe windows/linux/android but cannot MAC?)
Being able to add support for iOS compilation if the need arises.
Would be nice if the invocation interface was similar to that of autotools, since it is the one many people know and it is well documented.
Some questions:
If I have some rare requirement, which build system would be more ready to be extended?
Are both currently well maintained? (I wonder about waf mainly).
Community: if I find a problem, both communities are big enough to support me, in your experience?
For now my feeling is that I favour waf a bit as a tool, but cmake seems to have been quite successful for whatever reason.
Don't know much about waf, but CMake fits your requirements pretty well. I do know waf is written in Python, my personal favourite programming language ATM.
My primary requirements are:
Must be able to compile software in windows/linux and android.
CMake does Windows and Linux very well but so does any other build system worth its salt.
Someone wrote some Android scripts for CMake. Can't find anything similar for waf (my Google-fu turns up nothing.)
Must be ready to run tests.
CMake has a sibling testing framework.
Must be able to play nicely with other libraries that must be compiled with another build system but most likely will have to be compiled from source.
CMake has good integration with pkg-config, and can link against arbitrary shared libraries.
Must be able to add custom steps, like for example, generating some data from some files (mainly graphics) before compiling, all integrated in the build system.
CMake can generate custom rules.
Some strong preferences are:
Being ready to support MAC compilation.
CMake supports Mac quite well. It will even make you an Xcode project if you want, but it can also do command line builds.
Being able to cross-compile from linux as many platforms as I can (maybe windows/linux/android but cannot MAC?)
Cross-compiling is supported in CMake. CMake will not be the primary source of pain with cross-compiling - literally everything else will.
Especially with regards to cross-compiling for Mac. It's possible, but not worth it to cross-compile for that platform, considering you need access to a Mac anyways to get the libraries and header files, you need to patch GCC and clang and LLVM, etc. The only sound reason I've heard for going through this much pain is running an automated build server. Anyways, if you get a working Linux -> Mac toolchain, you should be able to cross-compile with CMake as if it were any other Unix platform.
Being able to add support for iOS compilation if the need arises.
iOS cross-compilation can be done, but you need a Mac.
Would be nice if the invocation interface was similar to that of autotools, since it is the one many people know and it is well documented.
Write a configure script that just calls CMake (cmake .). Then your users can do a ./configure && make && make install on platforms where that makes sense. There's also CPack which lets you generate DEB, RPM, NSIS (Windows) and DMG (Mac) installers/packages.
Some questions:
If I have some rare requirement, which build system would be more ready to be extended?
CMake is very extensible. It can be extended to support new languages and target platforms. (Given that waf is written in Python, it's going to be pretty hackable too.)
Are both currently well maintained? (I wonder about waf mainly).
CMake is mature and well-maintained.
Community: if I find a problem, both communities are big enough to support me, in your experience?
The community and extensions available are what keeps me coming back to CMake, from things like bakefile, honestly.
WAF
is pure Python
becomes part of your project, i.e. no external dependency
supports many build tools
can be used to do all kind of automations, not just building
It works perfectly for Linux, Mac or Windows.
On Android, gradle is the chosen build tool of Google. To use that is
wise, because it is set up to work by Google. You can call waf from
gradle and vice-versa, though.
If you want to learn all the low level Android
SDK tools, you could also use
WAF directly.
The SDK has
javac for Android Runtime (formerly Dalvik), Android\'s JVM, and produces a .class file
jar can also be used for Android
d8 (formerly dx) produces .dex files, with Dalvik executable code
aapt2 can then produce the .apk
javac and jar are known to WAF. For dx and aapt2 you would need
to create your own tasks, which is very
easy.
You would best make a WAF tool and
share it. Tools are either part of WAF or there is
waftools.
There are also these Steinwurf
tools.
If you make Android native code using
NDK:
you use CLANG, which is known to WAF
Further on you mentioned requirements:
WAF has waf_unit_test
WAF can do gnu_cross compilation. The Gnu toolchain knowns many
targets. But for Android you would need to set things up yourself
using the SDK or NDK. For NDK you could use the Gnu toolchain.
You would do waf configure, waf build instead of configure,
make, but you could wrap a Configure or Makefile around waf to
have the same commands.
WAF is very easily extendible with Python
WAF is now on gitlab and
constantly worked on.
The community is surely smaller than for CMake. But it is Python.
You can look into it and find out for yourself. You can also
contribute and become part of the community.
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.
I would like to run a small Windows program on an Android slate. It runs just fine under Wine in Ubuntu, but I am unsure how to install & run Wine on the Android slate.
Sorry if it's not strictly a programming question. If you want it to be so, I could rephrase it as "will I have to write my Delphi code again Java in order to run it on an Android slate?"
but I am unsure how to install & run Wine on the Android slate.
I sincerely doubt that is possible or will be within the next decade. While Android runs a Linux kernel, most of what WINE depends upon in Linux will look very different on Android. Not to mention the opcode issue noted by JOTN.
"will I have to write my Delphi code again Java in order to run it on an Android slate?"
Most likely. I don't know what "my Delphi code" entails. If it is pure algorithm stuff, conceivably you could use Free Pascal to get an ARM library you could link to via the Android NDK. If, however, "my Delphi code" involves the UI and the like, you would have to rewrite it (or cook up your own Delphi->Android translator) to get it to use Android's widget library.
I don't believe it will work because you would be trying to run x86 software on a non-x86 processor. To start you would need binaries compiled for an ARM processor.
If your windows program has any GUI, then it will definitely not work. Wine relies on an X-windows system when Android has its own graphical framework...
I've been looking at something similar recently. Wine doesn't run on anything that is not x86, period. When you introduce a GUI (as noted by Matthieu), anything outside of wine will need to utilise another graphics libraries.
It might be worth mentioning wine-lib, you can use this with gcc to cross complile to ARM but you'll end up in a 'world of pain' as soon as you have a GUI. I cannot be 100% but my guess is you're in for a rewrite. http://wiki.winehq.org/ARM
If you do go for a rewrite perhaps look at other languages as Java for android is not nessarliy the same Java you'll run on your desktop. http://www.oreillynet.com/onjava/blog/2007/11/dalvik_googles_tweaked_nonstan.html
I know it's a bit of a 'fad' but you might be best looking at html5/webapp or using c/c++ and gtk/qt if you can find work-arounds.
You can, but it is not easy and possibly too slow. The experimental process is described here: http://forum.xda-developers.com/showthread.php?t=1258506
It is a multi-step process. First you get an Ubuntu system image and chroot into that. Then from there you can invoke wine to display on the local vncserver. Then you install a vncviewer app on android to view the GUI.
Your android device would need to have an x86 CPU. So far, only netbooks will work for this as I don't believe there are any tablets available with x86 and Android compatability. I would only recommend going this route for fun and experimentation -- not productivity.
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.