Does Android support splice() and sendfile()?
These are Linux kernel calls, so they do exist on Android.
The more interesting question is if Bionic libc provides wrappers as it does for most ordinarily used system calls, or if you will have to invoke them directly. Additionally, apart from being included in Bionic there is the question of the functionality being exported for general use in the NDK.
It appears that sendfile() has been there since the first NDK release.
splice() has not historically seemed to be part of the NDK (I did not check the latest), though it was added to the AOSP sources of Bionic libc in June 2014.
Incidentally grep -r on relevant parts of the NDK installation and/or an AOSP Bionic checkout is a quick way to look into things like this.
Ndk doesn't support splice(). When I was trying to compile dirtypipe exploit for android.
Related
I am interested in building an open source project and it requires the GNU libraries GLIBC and GLIBM. If I were to cross-compile this under Linux (I am using Ubuntu 11.10 as the host) for a shared (.so), or even a static (.a) object, with the ARMv7-a neon architecture, using API-9, as a library to call with Java's JNI, to ultimately compile as an APK for distribution, what steps would one undertake to achieve this outcome?
Given I have tried the Google NDK toolchain (setting $PATH and $CC the hard and easy way according to the documentation), a variety of custom toolchains, the Code Sourcery toolchain and a toolchain suggested on the XDA forum using crosstool-ng, is it possible to achieve a shared object file that can be called from JNI and has access to the full GLIBC library on a non-rooted Android device?
I have searched for an answer to this and the closest I have come is to build GLIBC and GLIBM locally and copy the relevant object (.o) files and link manually using the NDK's arm-linux-androideabi-ld. The libc.so.6 file from Crosstool-ng and CodeSourcery will not work as the relocations fail (giving error unknown reloc type 19) when calling the library using Java's System.LoadLibarary(). My knowledge of relocations is not the best but from what I have read this would require changes to the /linux/elf.h header file, but I am not sure exactly where to go from there.
I believe from what I have read that it may be possible to make a static executable that has all dependencies resolved when linked but then it would not be possible to package this as an APK file as far as I'm aware.
Surely I can't be the first to want to compile C code against something other than Bionic for the Android platform? There are so many C projects that could be ported to Android and apparently GLIBC has been available on iPhone for quite a while.
Any low level C library has very tight ties with the OS itself. While Linux and Android may mostly be the same thing, they are not. Building against another C library will require said C library to be ported first.
I'm fascinated by the Pure algebraic/functional language. The Pure interpreter uses the LLVM JIT compiler as its backend.
I would like to compile Pure so that it runs on Android(ARM). Pure has a dependency on the LLVM JIT. So I need to compile LLVM source for Pure to run.
Is it possible to compile LLVM source for Android (ARM) devices? There really seems to be no information about this on the web. Maybe my search terms are wrong. Searching for Android LLVM does not bring up many good hits either.
It now seems possible, the NDK now supports Clang which uses LLVM. So maybe it can be made to work with any LLVM language. AOSP should give us some insight on how they added Clang support. See the latest Android NDK for details on Clang support.
Android NDK, Revision 8c (November 2012)
Important changes:
Added the Clang 3.1 compiler to the NDK. The GNU Compiler Collection (GCC) 4.6 is still the default, so you must explicitly enable the Clang compiler option as follows:
For ndk-build, export NDK_TOOLCHAIN_VERSION=clang3.1 or add this environment variable setting to Application.mk.
For standalone builds, add --llvm-version=3.1 to make-standalone-toolchain.sh and replace CC and CXX in your makefile with /bin/clang and /bin/clang++. See STANDALONE-TOOLCHAIN.html for details.
Note: This feature is experimental. Please try it and report any issues.
While you can surely compile LLVM on ARM (it's pretty trivial - just ordinary configure + make system), you're still out of luck: JIT on ARM is still work-in-progress, so I'd not expect it working for everything non-trivial.
It seems like the Android NDK would help in this, as one of its usages per its FAQ page is to reuse C/C++ code.
I think we shuld see on mix of LLVM + Android NDK (C++).
I'm thinking about SmallTalk-like dymanic object system (*), and LLVM usage is very interesting for lazy dynamic compilation on Android devices.
First try you shuld build something like tiny Buildroot/OpenWrt Linux system (or build you own using CLFS or my scripts: https://github.com/ponyatov/L/tree/clock )
for ARM device like Raspberry Pi (it's my case for testing). If you got good results on this variant, later you can migrate to Android device itself. I think you'll need some C++/NDK glue code to adopt LLVM/Pure core vs Android runtime and GUI. (**)
(*) but with my own language syntax, lisp-like functional abilities to mutate all system internals, parser/compiler integrated framework, and maybe some basics of symbolic computer algebra
(**) is Android Pi alive ?
As far as I know you can't build LLVM for ARM devices just yet.
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.
the Android ndk is hard to use for the old autoconf based code, so i employed scratchbox2/emdebian to have a complete build environment. can i build a shared library in emdebian (arch is armel) and then use it in android?
The official NDK comes with a version of GCC that works with Google's custom Bionic libc. If you are using a version of GCC that is intended to work with the GNU libc then you must statically link it in (as is done by the Crystax NDK). So even if your compiler generates the correct instructions, it may be worthwhile to rework your build environment to avoid bloating your application unnecessarily.
armel is Arm Eabi. Android is ARMv5 eABI. They will probably be compatible.
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