I've managed to get a native C application working in the emulator.
For those who are interested, here's how:
1) Create your hello world program:
#include <stdio.h>
int main(int argc, char** argv) { printf("hello world\n"); return 0;
}
2) Compile with an arm cross-compiler toolchain. I used a toolchain I built with gentoo's crossdev tool, but there are lots out there. Assuming your c file is hi.c and your cross compiler is called armv6- vfp-linux-gnueabi-gcc, you can compile using:
armv6-vfp-linux-gnueabi-gcc hi.c -o hi -static
Note the -static. I've not figured out the version of libc etc or the ABI used yet, so for now, link applications statically.
3) Copy to a running emulator: adb push hi /system/sbin/hi
4) Run it! From the emulator console: cd /system/sbin ./hi
5) Smile as you see "hello world" printed on the console. :-)
Next, I'm going to try and get busybox up & running so we can have access to exciting programs such as "cp"! After that, perhaps dropbear for remote ssh access? Or maybe a small web server like boa so we can turn the android emulator into a webserver? Stay tuned.
> 2) Compile with an arm cross-compiler toolchain. I used a toolchain I > built with gentoo's crossdev tool, but there are lots out there. > Assuming your c file is hi.c and your cross compiler is called armv6- > vfp-linux-gnueabi-gcc, you can compile using:
> armv6-vfp-linux-gnueabi-gcc hi.c -o hi -static
> Note the -static. I've not figured out the version of libc etc or the > ABI used yet, so for now, link applications statically.
> 3) Copy to a running emulator: > adb push hi /system/sbin/hi
> 4) Run it! From the emulator console: > cd /system/sbin > ./hi
> 5) Smile as you see "hello world" printed on the console. :-)
> Next, I'm going to try and get busybox up & running so we can have > access to exciting programs such as "cp"! After that, perhaps dropbear > for remote ssh access? Or maybe a small web server like boa so we can > turn the android emulator into a webserver? Stay tuned.
I just noticed that some classes in Android.jar used the keyword "native". It should be a matter of time to get either offical or unofficial suport for calling native code from the Dalvik VM.
On Nov 13, 9:31 am, TomCooksey <TomCook...@googlemail.com> wrote:
> 2) Compile with an arm cross-compiler toolchain. I used a toolchain I > built with gentoo's crossdev tool, but there are lots out there. > Assuming your c file is hi.c and your cross compiler is called armv6- > vfp-linux-gnueabi-gcc, you can compile using:
> armv6-vfp-linux-gnueabi-gcc hi.c -o hi -static
> Note the -static. I've not figured out the version of libc etc or the > ABI used yet, so for now, link applications statically.
> 3) Copy to a running emulator: > adb push hi /system/sbin/hi
> 4) Run it! From the emulator console: > cd /system/sbin > ./hi
> 5) Smile as you see "hello world" printed on the console. :-)
> Next, I'm going to try and get busybox up & running so we can have > access to exciting programs such as "cp"! After that, perhaps dropbear > for remote ssh access? Or maybe a small web server like boa so we can > turn the android emulator into a webserver? Stay tuned.
On Nov 13, 2007 6:40 PM, Jingtao Wang <jingt...@gmail.com> wrote:
> Excellent work!
> I just noticed that some classes in Android.jar used the keyword > "native". It should be a matter of time to get either offical or > unofficial suport for calling native code from the Dalvik VM.
this is what i mentioned in an earlier thread (titled JNI: ....)
javah is typically used to build a header file which defines the native object interface for the compiled native code from java.
from here, you should be able to compile a shared library, in this case for ARM that uses Java as an executable launching environment yet actually runs code natively.
you can also look at System.exec() - which is defined within the android developer documentation.
having JNI functioning would be all that i would require for my multi-platform development kit. i can use the Java base to be my interface to the device and operating system, yet call my code natively (the code which is not platform dependent)
> 2) Compile with an arm cross-compiler toolchain. I used a toolchain I > built with gentoo's crossdev tool, but there are lots out there. > Assuming your c file is hi.c and your cross compiler is called armv6- > vfp-linux-gnueabi-gcc, you can compile using:
> armv6-vfp-linux-gnueabi-gcc hi.c -o hi -static
> Note the -static. I've not figured out the version of libc etc or the > ABI used yet, so for now, link applications statically.
> 3) Copy to a running emulator: > adb push hi /system/sbin/hi
> 4) Run it! From the emulator console: > cd /system/sbin > ./hi
> 5) Smile as you see "hello world" printed on the console. :-)
> Next, I'm going to try and get busybox up & running so we can have > access to exciting programs such as "cp"! After that, perhaps dropbear > for remote ssh access? Or maybe a small web server like boa so we can > turn the android emulator into a webserver? Stay tuned.
I am thinking just a bit down the future. So we have our .so files and we have Android. How will we gain access to the boot loader in order to install the libraries? When I worked at a mostly Microsoft OEM Jtags were used but this may not be an option.
On Nov 13, 12:50 pm, "Aaron Ardiri" <ard...@gmail.com> wrote:
What I was trying to say is - after looking at some of the compiled bytecode in Android.jar, it's obvious that some functions in the current SDK were implemented in native code,
e.g. public static final native int getCallingPid(); in class android.os.BinderNative
I'm not sure whether this native interface is 100% compatible with Sun's JNI definations through.
On Nov 13, 9:45 am, "Aaron Ardiri" <ard...@gmail.com> wrote:
> On Nov 13, 2007 6:40 PM, Jingtao Wang <jingt...@gmail.com> wrote:
> > Excellent work!
> > I just noticed that some classes in Android.jar used the keyword > > "native". It should be a matter of time to get either offical or > > unofficial suport for calling native code from the Dalvik VM.
> this is what i mentioned in an earlier thread (titled JNI: ....)
> 2) Compile with an arm cross-compiler toolchain. I used a toolchain I > built with gentoo's crossdev tool, but there are lots out there. > Assuming your c file is hi.c and your cross compiler is called armv6- > vfp-linux-gnueabi-gcc, you can compile using:
> armv6-vfp-linux-gnueabi-gcc hi.c -o hi -static
> Note the -static. I've not figured out the version of libc etc or the > ABI used yet, so for now, link applications statically.
> 3) Copy to a running emulator: > adb push hi /system/sbin/hi
> 4) Run it! From the emulator console: > cd /system/sbin > ./hi
> 5) Smile as you see "hello world" printed on the console. :-)
> Next, I'm going to try and get busybox up & running so we can have > access to exciting programs such as "cp"! After that, perhaps dropbear > for remote ssh access? Or maybe a small web server like boa so we can > turn the android emulator into a webserver? Stay tuned.
On Nov 13, 2007 6:57 PM, Akeem A. <akeem.aden...@gmail.com> wrote:
> I am thinking just a bit down the future. So we have our .so files and > we have Android. How will we gain access to the boot loader in order > to install the libraries? When I worked at a mostly Microsoft OEM > Jtags were used but this may not be an option.
why can the .so files not be shipped with the .apkg files?
the shared libraries may be shared, but honestly they only need to be avalable to the application that we install. the could be like a normal resource, we just have to make sure that loadLibrary() allows for searching of the .so files within the application path.
the question is what is the android equivalent to javah and the include files necessary to build the JNI binaries.
i am yet to install the SDK yet (been very busy today) - but, i am sure when we have dug around deep enough we will find all of these things. what we then need is:
a) detect cpu architecture at runtime (load alternative library) b) the ability to put .so files in our .apkg files c) simply use the android launcher to load our application
i used to do a lot of JNI work back in 1997/1998 where i cross compiled a lot of image processing stuff between windows, linux and solaris. its not a question os how, its when :)
