There are a plethora of low-cost ARM-based mini-devices coming out (Cotton Candy, etc). Some of these are Android-only, some Linux-only, and some allow both operating systems to run.

The only issue is: all of these are ARM-based devices. While Android apps can run on Android on both x86 and ARM, I'm having a hard time finding useful apps that run on Linux on ARM - in fact, even Ubuntu on ARM is still not that well supported.

I have two related questions:

  1. Is it hard to make low-cost x86 devices that can run Ubuntu/Linux and relevant x86 applications?
  2. How is it that Android apps can run seamlessly on x86 and ARM, while Linux applications have to be recompiled for ARM?
  • 1
    Debian ARM is an official port and pretty well supported.
    – jordanm
    Jan 16, 2013 at 22:20
  • Thanks, would you know about the status of GNOME and popular apps (LibreOffice, Eclipse, etc) on Debian/ARM?
    – Suman
    Jan 16, 2013 at 22:26
  • 1
    You can check on the Debian packages site. When you search for a package, it displays the supported architectures. See this for an example with libreoffice.
    – jordanm
    Jan 16, 2013 at 22:31

2 Answers 2


"Linux", strictly speaking, is an operating system kernel used by both Android and the unix-like operating system referred to colloquially as linux, and sometimes more formally as GNU/Linux which we know via distributions such as ubuntu and debian. Linux, the operating system kernel, is written in C and must be compiled to native machine code.

I think jordanm did a good job of responding to question #2 regarding user space differences between GNU/Linux and Android. Here's the Android stack:

Linux (native machine code, instantiated by bootloader)
Dalvik (native machine code, instantiated by linux)
Application (java bytecode instantiated by dalvik)

Dalvik is a "virtual machine" which runtime interprets bytecode, and the bytecode is precompiled from java. In other words, it is a user space application that is running all the time like a server, and it handles requests to process bytecode. Android applications are written in java, precompiled to bytecode, and run inside the dalvik virtual machine.

This is very similar to what runtime interpreters such as the shell, python, perl, ruby, and javascript do in the sense that it means code written for those interpreters will work if the interpreter does. They do not all have the same strategy with regard to the stages between code and execution, but that is another topic.

Those interpreters are all run by an operating system kernel, which also runs the computer. Both the kernel and the interpreter exist on disk as machine code; the kernel is boot loaded into ram and henceforth the fundamental instruction stream running through the processor is the kernel's; the kernel can also stream instructions from other machine code artifacts it loads into ram (such as the dalvik virtual machine, or the init daemon, or the shell, or the X server) and it is the combined logic of the system which interleaves instructions in the processor stream such that the kernel maintains its role and cannot be displaced. It is the gatekeeper of all hardware, so a lot of roads lead back to it and it controls the clock.

Portability for user land applications is simplified for android/dalvik just as it is simplified for perl or python. It is compiled from code as a form of optimization, not in order to meet the needs of any specific architecture. The interpreter is what, like the kernel, must be configured and compiled in an architecture specific way.

Now here is the GNU/Linux stack:

Linux (native machine code, instantiated by bootloader) 
Application (native machine code, instantiated by linux)

Applications here include the shell and the init daemon. Shell scripts are not applications in this sense as they are interpreted by the shell, and neither are java, python, perl, etc. programs, but applications started from the shell or by the init daemon are if they exist on disk as native machine code, because init and the shell actually ask the kernel to do this for them -- they cannot do it themselves.

All those applications -- the shell, the init daemon, the X server, your web browser, mostly written in C or C++ -- must be individually compiled into an architecture specific form.

Hope that sheds some light. With regard to linux on ARM, there are two primary streams, one for the armv6 instruction set used on the Raspberry Pi -- these are specialized -- and one more general steam for armv7, which I believe includes most mobile devices. The fedora, debian, ubuntu, etc. ARM distributions are the latter, wheras pidora, raspbian, etc. are the former.

  • Thanks for the really detailed reply. Do you know of any Raspberry Pi and other ARM Linux distros that have a GUI built in?
    – Suman
    Jan 17, 2013 at 15:13
  • 1
    @Suman : I don't have one yet (it's coming soon :) ) but since the Pi has HD video I would assume all the Pi distros have X and so on available in their repo. This one: fedoraproject.org/wiki/Raspberry_Pi appears to have it by default, using XFCE. There's also a reference there to the official fedora 18 ARM distro, which is probably for more general use (ie, is not Pi-centric).
    – goldilocks
    Jan 18, 2013 at 14:34
  • Thanks, I did some digging and found that the Raspbian image does include LXDE, so just need a Pi box to test it out on now. :)
    – Suman
    Jan 18, 2013 at 15:48

I will address the second question since is more on topic with the site. Android apps run a process virtual machine known as Dalvik. This is very similar to java's JVM. The whole idea behind this is "write once, run anywhere". The Java code is not compiled to native machine code, it is compiled to bytecode that can be executed by the VM. With a language such as C, the code is compiled into machine code, that varies depending on architecture.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.