Android - Is Android a 32-bit or 64-bit OS?

In the realm of the ARM chipsets which is the common factor, the entire Android stack, from the near-identical kernel based on Linux, are in fact, 32bit, cross-compiled from usually either a 32bit/64bit host environment, the host environment is usually one of the distributions of Linux. Recommended distribution, by Google, for building and cross-compiling Android is Ubuntu.

The Android run-time library (media, graphics, filesystem, to name but a few) are also 32bit, but as we reach the layer of the dalvikvm, then the number of bits becomes irrelevant as it is at this point, the apks coming from the Google Play Store are native bytecode (A "by-product" of generated Java code compiled into a portable bytecode) which targets the DalvikVM (Virtual Machine) which in turn interprets and translates the bytecode targetting the raw ARM instruction set.

Froyo was the last Android that enabled compilation under a 32bit hosted environment in which it was cross-compiled targetting the ARM chipset.

Gingerbread was the first of "future" Android, back then circa, three years ago, that introduced a requirement to use a 64bit hosted environment in which it was built. There was many hacks to get Gingerbread to be built under 32bit hosted environment.

ICS and JB, and upwards now definitely requires a 64bit environment to speed up compilation and to reduce turn-around time in building.

So to sum up, what you see on the Play Store has no bearing on whether 32bit or 64bit are used and thus irrelevant.

Side note: Typical 16GB RAM/Quad core/64bit Linux distribution, the time it takes to build ICS from scratch, takes 30minutes maximum, had this being a 32bit Linux distribution, it would have taken longer, in fact, may cause a CPU meltdown as there is simply, not enough processing power to churn and crank out cross-compiled code, which is a very demanding and taxing process!

Proof of this.

Pull in any native ARM binary found in /system/bin or /system/xbin, for example, /system/bin/dalvikvm, this is the Dalvik VM binary that is responsible for the upper layers of Java and APKs.

Now, examine the binary by issuing this command: file dalvikvm which gives a summary of the type of file it is, the expected output would be this:

dalvikvm: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped

Notice the reference to 32-bit ELF, and is cross-compiled to ARM and is a binary executable.

Right, moving on, let's inspect a native shared library found in /system/lib, for example, /system/lib/libandroid_runtime.so, now issue file libandroid_runtime.so, the expected output would be this:

libandroid_runtime.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped

Again, notice, its 32-bit ELF, cross-compiled to ARM and is a shared library.

The key to the host's cross-compilation can be found in the AOSP source, i.e., Gingerbread build originally had a requirement to be built on a 64bit host system, here's the newsgroup linky referring to how to patch the scripts to get it to build on 32bit host which has two patches, found here, for build/core.mk and build/main.mk (combined) on AOSP's Gerrit review.

As a subsequent result, this patch had made its way to ICS's build scripts in which I did have the privilege of compiling ICS on a 32bit platform which took 3 days to build (it was a port of ICS for the Zte Blade). Now, the requirements are ramped up, you do definitely need 64bit host to enable cross-compilation of building AOSP from ICS upwards :)

Originally, Android was written for 32-bit processors only: and specifically, 32-bit ARM processors. Later, Intel and MIPS invested a lot into making Android support their architectures too: but still only 32-bit processors. They were able to do this without (many) compatibility problems, because most apps aren't shipped as binaries. Written in Java, they are instead shipped as bytecode, which a virtual machine on the phone compiles to the phone's architecture when the app is run. Some apps include native components, which are shipped as a binary. This is done to make some kinds of apps faster (particularly games), or to let the app access C libraries that aren't available in Java. Those apps can include more than one binary for the native code parts, to allow them to run on different architectures. Even so, the majority of apps are Java-only, so they just work on any architecture.

The above was all true at the time this question (and most of the other answers) was written, but no longer. Lollipop introduced support for the new 64-bit ARM processors (ARMv8) as well as for Intel and AMD's x86_64 processors, which means that Android now supports both 32-bit and 64-bit processors. The Nexus 9 was the first flagship 64-bit Android device. As well as giving access to new instruction set extensions, 64-bit support means that apps can use more than 4 GB of RAM. Most apps won't need that much, but high-end games and photo/video creation software can certainly make use of it: pushing Android towards being a platform for console-quality games (including VR games) and for creating content. Java apps don't need to be updated to take advantage of this, because the virtual machine always compiles them to the phone's architecture, but apps with native code will.

Because ARMv8 is backwards-compatible with 32-bit code (the same way x86_64 can still run x86 code), even apps which include native code for 32-bit processors can still run on 64-bit Android. So an app only needs to be compiled for 64-bit if it contains native code and it wants to take advantage of the higher RAM limit or the new features of the architecture.

All ARM chips are currently 32-bit. Because of this, Android currently executes all code in a 32-bit environment.

64-bit processors set to launch in 2014.