I'd like to know the technical difficulty in porting Android to x86 architecture.
Since its source is open, what is the main difficulty in getting to run on x86?
Or is it correct to ask why it cannot be compiled to a Java bytecode to run on a JVM on a PC? Is it because of the Dalvik VM?
I'd appreciate if somebody could explain this.
Thank you.
Actually, it is already ported to x86: http://www.android-x86.org/
Also, Android does not run in a JVM. The Android Kernel is a modified Linux Kernel and written in C. You can't compile it to run in a JVM.
The DVM (used by Android) is a modified JVM based on the OpenSource JVM-implementation Apache Harmony. All Java-Applications on Android run in a DVM.
There isn't a problem. VirtualBox can run an android OS guest machine just fine.
The main difficulty is that x86 and ARM are totally different architectures. They have a totally different mentality about them, different instructions, different registers, different behaviours, different memory architecture, etc. Even the way they interface with other hardware is different.
In terms of technical difficulty, the architectures don't have instructions or mechanisms that are compatible with each other, so the behaviour that is relied upon by a compiler for ARM does not exist on x86, and vice versa.
Knowing enough about one of them to implement anything major usually means you've not spent much time dealing with the other, which just adds to the difficulty.
Related
I'm new to android programming, I was reading the answers on this question Why shouldn't an Android app be written in C/C++ because you "simply prefer to program in C/C++"?
in the first answer by Devunwired. he mentioned that "your native code must be built into .so files (one for armv5, armv7 and x86) all packaged up into the same APK. This duplication of executable code makes your app 3x the size (i.e. a "fat binary") unless you take on the task of building separate APKs for each architecture when you distribute the application"
My question is, I always thought that Operating Systems in general provide an abstraction over the underlying architecture. So if I want to deploy a c/c++ program on different environments, I need to re-compile the source code using a compiler written for different operating systems, this operating system however might have different versions that support different architecture.
If I'm right then why the case is different when it comes to Android?
At some point the operating system hands the code over to the CPU. The binary must have instructions for that particular CPU. With Java each OS and CPU makes the same virtual machine available so you don't have the same considerations.
OK this is a strange one:
Is there a way someone can develop native C applications or libraries for Android without using the Android NDK?
What was happening before the NDK was released?
(It's not there for too long, I think it was released only one or two years ago).
Apparently, you can -- a friend of mine is a real Android guru and he managed to build a GCC-based native toolchain entirely by hand. He also fixed some missing parts in Android's libc. The main idea is the following: GCC has builtin support for the arm-elf-linux target, so with an appropriate build script, you can configure it to build for Android. However, you have to root the phone to run the resulting binaries. One even cooler thing is that because GCC is a self-hosting compiler, with the arm-linux-elf toolchain, you can recompile GCC once again and have the toolchain on the phone itself.
Before the NDK was released, the only officially supported way of developing Android applications was to use the Android SDK and writing your applications in Java.
As others have mentioned, it's possible to cross-compile some applications as completely stand-alone and run them on a rooted phone. The downsides of this should be obvious: very few people will be able to run your application (they also need to be root, plus you won't be able to get your application up on the Play store); and you might even run into compatibility problems yourself across different devices e.g. if you rely on dynamic linking against various libraries (which you might need to do in order to keep the size of the binary down).
TL;DR: it's possible, but severly limited, and not recommended.
You can compile your C code with an Android-compatible toolchain (such as CodeSourcery) and run it on a non-rooted phone, from its command line (for example through an SSH connection like SSHDroid).
I just got a EEE pad transformer. Like any hardware I own I'd like to have a C compiler on it. I know I can cross compile, but I'd like to do development ON the device itself. I've searched google and all I can seem to find are pages on how to build an arm toolchain for x86/64 Linux. Thoughts?
The process of building gcc (et al.) to run on your target should be similar to building a cross-compiler, excepting that you will:
need to have an ARM cross compiler that runs on your, for example, x86 machine. So the results of your googleing are still useful.
use the --host option to specify your ARM platform when running configure for all of the parts of your toolchain.
Since you asked about this in June, 2011, (or maybe starting right around that same time) there's something that does EXACTLY what you want called "Terminal-IDE." This is a much better answer than the one you checked off as correct because it doesn't rely upon cross-compilation as the checked answer does.
Terminal-IDE is an Integrated Development Environment that runs ON your Android device (just as you asked about), and has both a C compiler and Java (of course).
There's a Terminal-IDE web site with a more in-depth description and links to other resources.
NOTE: Since I wrote this reply, the author of Terminal-IDE has stopped supporting it.
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.