Hi!
I'm trying to build some native apps for G1 with Scratchbox.
So far I'm able to produce a statically linked binary.
As I understand linking dynamically is not trivial as Android has its own libc - bionic.
I found herethat
To make an executable compatible with Android's libc (bionic), one has to force the compiler to include a few Android's special include files at the compile time and do a few other tricks at the link time.
Could someone comment on this? Which tricks do I need to do at the link time? Does anyone have experience doing that? Is dynamic linking against bionic possible at all with Scratchbox?
Thanks!
Related
I'm just wondering is anyone trying this yet? i mean is it even possible?
Just a thought for you big shot android devs out there JF, Haykuro, LucidREM
Google "android jni"
Well, a quick trip around google would have helped you.
Android is using java, and currently it's not possible to use anything else.
But anyway, would you rather compile all of your code for multiple architectures? J makes things easier here...
You can write cli-apps in C though... i heard something about that there was plans to make other languages available in android, but i wouldn't hold my breath
Also, why is this related to JF/Haykuro/LucidREM?
I think you can do this with JNI: http://en.wikipedia.org/wiki/Java_Native_Interface
Using an ARM native compiler (such as the ones at CodeSourcery, http://www.codesourcery.com/sgpp/lite/arm/portal/[email protected]=lite) you can compile your apps and run them fine on the G1
Code:
$ arm-none-linux-gnueabi-gcc -static foo.c -o foo
$ adb push foo /data/foo # we are pushing to /data as it is +rwx (read, write, execute) for a standard user.
$ adb shell /data/foo
a=1
b=2
foo=a+b
foo=3
^^^
OH I love when I stumble across a post like this and have something new to play with.
The problem is due to the different location of the linker and mainly the different libc you have to statically link everything.
I have been having a hell of a time getting DPKG to build statically.
I picked up a copy of the newly released book, Unlocking Android, at Barnes and Noble yesterday. There is a whole chapter devoted to writing native apps using C (and ARM assembler) with the CodeSourcery tools linked above. The author walks through the steps you need to do to dynamically link the libraries so you don't end up with enormous statically linked executables. Well worth the price.
It is surprising what you can do with C on the phone, its actually not too difficult. The method outlined below doesn't use the non native toolchains and if you use the sourcery toolchain (as mentioned above) you will end up with bigger binaries as you need to link in a standard glibc and not androids bionic libc. This may or may not be important for your project.
The other advantage of the steps below is that you will build and link against any library that is available to the android platform
The easiest way that I've found to start when porting or writing new applications is this method.
1) Check out the current git android source.
2) Build the entire tree, "make" in the top level directory.
3) Create a new directory in mydroid/external/packagename/
4) Copy one of the simple android Android.mk (Make) files from a "like" target.
(If doing a library, choose a library, if coding an executable , choose that).
5) source the mydroid/build/envsetup.sh in the users bashrc
6) cd to your directory, then instead of the usual "make" do an mm.
This should create a binary, which you can adb push to the phone and run at the console.
You can do all the usual things if linked properly, like write the framebuffer using sdl, play sounds, create network connections.
Just remember that you dont have a standard libc (glibc) to play around with you have "bionic". If you are missing your favourite glibc function , it is probably intention and not abug. You'll either need to port it or make do with the functions provided by bionic.
These instructions are for a "pure" C program. you can mix the java like dex calling by 'shelling' out to the C application when you need performance, however premature optimization is the root of all evil, you'll be surprised what performance you can pull from davlik (And I expect the VM guys to improve this even further).
I know that is a lot to digest. Will do the best I can to answer your questions. I'm by no means an expert in the area, but have learned a bit about C on android.
Well I don't know much about all this but what i know is that e.g.
ScummVM IS written in C++ , and so is g-arcade.
His FAQ says:
"How did you do this? Is it Java?
No. ScummVM is a C++ program. For this port, I turned it into a really big JNI library so Android still thinks it's running a Java program, but almost all of it is implemented in C++."
(http://sites.google.com/site/scummvmandroid/faq#TOC-How-did-you-do-this-Is-it-Java-)
So if some1 wanna port MAME, feel free to xD
So this is probably a silly question.
I have this rather complicated app that would be a heck of a lot of work to convert to Java.
It runs in the command line and works fine in Linux.
Trying to run it fails, but x86 bytecode probably isn't very ARM friendly.
Is there a specific way I need to compile the application?
Is it even possible to run it from a console emulator?
Thanks.
Try Android NDK
I am also new to Android Dev ( 15+ years Linux, 10+ years Java, etc.)
I am not an expert but for your purposes you need the "Android NDK" in addition to the "Android SDK" that most developers utilize.
"The Android NDK is a toolset that lets you embed components that make use of native code in your Android applications.
Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts of your applications using native-code languages such as C and C++. "
Basically the tools are needed to cross compile C++ source code for the target ARM environment.
I am prevented from posting the download URL for some bizarre reason, but it is listed under "Native Development Tools" on the left side of the web page for the standard "Android SDK" download.
Yeah that's because you are new. It's a system to prevent spammers from posting URLs.
When you have a couple of posts the restriction will disappear
Anyway; found it, seems to be what I'm looking for.
I'll check it out in the morning.
Big thanks
Dmitry Moskalchukhas written a patch for the ndk to better support c++ see crytax dot net there are posts on google groups android-ndk talking about it
Thxs for the info. I was aware that the NDK did not include all of the libs that desktop Linux/UNIX developers expect. The suggested patched version adds the STL libs back in.
Sent from my PC36100 using XDA App
There are A LOT of libraries missing
I guess I'll just keep it a hosted app.
Thanks for all the input
Hello everyone. I'm looking for a way to use gcc make natively on Android. I know would supposedly be slow and heat up my cpu, but I don't get enough time on my computer to develop via a cross compiler.
Something like this would be ideal:
http://forum.xda-developers.com/showthread.php?t=1645182
I'd post there asking about a download link but the forums won't let me until I've made ten posts.
If anyone has any ideas how to get this working I'd love to hear them!
I found a gcc binary here:
rwiki.sciviews.org/doku.php?id=getting-started:installation:android
I don't know what version it us but it seems to run. I think I will try compiling gcc from scratch.
Can bionic libc be replaced with the full version of libc? Or would that break things?
Next up I think I'll try to get bash on this phone.
I'll post an update when I have gcc fully working.
I've found an app that does most of what I needed, called Terminal IDE on the play store. I now have a mostly functional development environment on my phone.
Next up, some of the open source software I want to port uses autoreconf, which is part of automake. Unfortunately, automake needs access to /tmp/ during configure, which doesn't exist. I guess I'll just have to edit the configure file on my PC and point it to a path that's accessible.
Does anyone know of an automake binary for Android?
I am fairly new to the game so this might have been solved before or maybe a project somewhere is already working on it, but I'll ask anyways...
I want to build a version of Android that runs on glibc but also has the Android specific libs to run it's framework, system services, dalvik, etc...
So I have the source for both as well as the sources for gcc 4.8.2, I am thinking I need to eleminate from bionic what exists in the gnu side of things, and then add what is left in bionic and doesn't exist in eglibc or the stdc++ library in gcc to that, or maybe the other way around. And then write an Android.mk file to build it with Cyanogenmod-10.3 in place of bionic.
Thats my game plan and I am sure there are some holes in it, maybe I need to modify the NDK as well, and I am sure I need to change some includes through-out the Android sources, or maybe write some headers that wrap around the eglibc version of the functions, methods, classes, etc.. that are named differently but are basically the same function.
Mabye someone with a bit more experience in the field can shed some light on what they think about the above.
Any guidance, references, quotes, links, articles, insight, or advice?
Hello,
I am posting to begin a thread regarding the native compilation and execution of OpenCL code on an ARM Android device, namely the HTC One M8.
I have used the app Linux Deploy to install a Debian desktop environment alongside Android, sharing the same Linux kernel but supplying different runtime libraries. Additionally, I have installed gcc/g++, Code::Blocks, and the OpenCL ICD and header files necessary to compile a native binary.
My intent is to continue developing a graphics render algorithm, but if I can get a working Android binary from g++ on a GNU toolchain, I would be happy to share generalized source code so that others can do the same with some simplicity.
Currently, I have success compiling a binary with shared libraries for GNU/Linux, but it does not detect the OpenCL devices on my system. I tried statically linking my application, but it refuses to link OpenCL statically.
The way I see it, there are two ways to solve my problem:
1) I assume Debian cannot see devices due to a driver issue, but I could be wrong, and I don't believe appropriate GNU drivers exist at this time. (Please correct me in a response if you know this to be false.) I have talked briefly with some of the folks from the Freedreno project, and it seems the OpenCL compiler is the biggest missing piece between the driver and the hardware. Unfortunately, I do not know if a working driver would even solve the issue in my case.
2) Compile binary with Android shared libraries. This may be most easily done with Eclipse, but I prefer Code::Blocks, so if the libraries could be linked in, then it may be trivial to change IDEs. I suppose it depends entirely on how the NDK handles compilation.
Option 2 is most likely the best course of action. I intend to publish my progress in milestones. Discuss.
XDA:DevDB Information
PLoW, Device Specific App for the Verizon HTC One (M8)
Contributors
Agenthex, agenthex
Version Information
Status: Testing
Created 2015-01-03
Last Updated 2015-01-03
Answer to your question = Mint 17.1 Works for me and this should be in general as this has nothing that you created.