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 :)
> 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.- Hide quoted text -
this is within the build.xml file - it seems the class files are converted to DEX files for installation onto the android platform. there may be some opportunity to look at compiling c/c++ code into DEX format.
something worth exploring? bah.. 1am.. time for bed :) enough fun for today
On Nov 13, 10:31 pm, TomCooksey <TomCook...@googlemail.com> wrote:
> I've managed to get a native C application working in the emulator.
thank you, Tom.
something similar happened when i was trying to develop C++ applications for EPOC R5 on the Psion Series 5mx.
the official SDK documentation focussed mainly on developing EPOC applications in C++, not C. that is not easy now with very little organized documentation. there are many classes and the arch is comples and so on.
i found out that there was a std C lib example also. with a little experimentation, i found that i could extend this project to build standard C++ code that needs a console only.
i finally managed to develop a huge single threaded C++ application which i used to to hook into multiple PCs.
of course, that ran using only a console. however, you may have many interesting appls that run only on consoles.
interested in finding out whether Android has an example of a console app?
I may be completely off topic here Tom, but Nokia has an open source port of the Apache httpd server (UNIX version) to the Symbian OS. Perhaps some opportunity for a port to Android? Or probably there is a raft of lightweight webservers out there any way? Details below:
> 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 yourcfile is hi.cand 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 runningemulator: > adb push hi /system/sbin/hi
> 4) Run it! From theemulatorconsole: > 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 androidemulatorinto a webserver? Stay tuned.
You don't need a native C implementation of a web server to run on in this platform. Yesterday I created one using "barehttp", there's quite a few Java web servers out there that are very lightweight.
Unfortunately I couldn't get the networking to work, when I try ot get the inet address of the phone I get an unknown host exception. So I don't know if this is some bug or security restriction I'm hitting.
On Nov 14, 8:10 am, cpedros <peropejo...@gmail.com> wrote:
> I may be completely off topic here Tom, but Nokia has an open source > port of the Apache httpd server (UNIX version) to the Symbian OS. > Perhaps some opportunity for a port to Android? Or probably there is a > raft of lightweight webservers out there any way? Details below:
> > 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 yourcfile is hi.cand 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 runningemulator: > > adb push hi /system/sbin/hi
> > 4) Run it! From theemulatorconsole: > > 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 androidemulatorinto a webserver? Stay tuned.
Very nice, Tom. I wonder if one can link against the "Surface Manager" component and write code directly to the screen somehow. Sounds like a good next step in the other direction... just for grins.