Solución:
En el ámbito de los conjuntos de chips ARM, que es el factor común, toda la pila de Android, del kernel casi idéntico basado en Linux, es de hecho, 32 bits, compilada de forma cruzada desde un entorno de host de 32 bits / 64 bits, el entorno de host suele ser una de las distribuciones de Linux. La distribución recomendada por Google para la compilación y compilación cruzada de Android es Ubuntu.
La biblioteca de tiempo de ejecución de Android (medios, gráficos, sistema de archivos, por nombrar solo algunos) también es de 32 bits, pero a medida que llegamos a la capa de dalvikvm, la cantidad de bits se vuelve irrelevante, ya que en este punto, los apks vienen de Google Play Store son códigos de bytes nativos (un “subproducto” del código Java generado compilado en un código de bytes portátil) que apunta a DalvikVM (máquina virtual) que a su vez interpreta y traduce el código de bytes que apunta al conjunto de instrucciones ARM sin procesar.
Froyo fue el último Android que permitió la compilación en un entorno alojado de 32 bits en el que se realizó una compilación cruzada con el objetivo del conjunto de chips ARM.
Gingerbread fue el primero de Android “futuro”, en ese entonces, hace tres años, que introdujo el requisito de utilizar un entorno alojado de 64 bits en el que se construyó. Hubo muchos trucos para que Gingerbread se construyera en un entorno alojado de 32 bits.
ICS y JB, y versiones posteriores, ahora definitivamente requieren un entorno de 64 bits para acelerar la compilación y reducir el tiempo de respuesta en la construcción.
Entonces, para resumir, lo que ve en Play Store no tiene relación con si se usan 32 bits o 64 bits y, por lo tanto, son irrelevantes.
Nota al margen: Distribución típica de 16GB RAM / Quad core / 64bit Linux, el tiempo que lleva construir ICS desde cero, toma 30 minutos como máximo, si se tratara de una distribución Linux de 32 bits, habría tomado más tiempo, de hecho, puede causar un colapso de la CPU ya que simplemente no hay suficiente potencia de procesamiento para generar y generar código compilado cruzado, que es un proceso muy exigente y agotador!
Prueba de ello.
Extraiga cualquier binario ARM nativo que se encuentre en /system/bin o /system/xbin, por ejemplo, /system/bin/dalvikvm, este es el binario Dalvik VM que es responsable de las capas superiores de Java y APK.
Ahora, examine el binario emitiendo este comando: file dalvikvm que da un resumen del tipo de archivo que es, el resultado esperado sería este:
dalvikvm: ejecutable ELF LSB de 32 bits, ARM, versión 1 (SYSV), vinculado dinámicamente (usa bibliotecas compartidas), despojado
Observe la referencia a ELF de 32 bits, y se compila en forma cruzada con ARM y es un ejecutable binario.
Bien, avanzando, inspeccionaremos una biblioteca compartida nativa que se encuentra en /system/lib, por ejemplo, /system/lib/libandroid_runtime.so, ahora emita file libandroid_runtime.so, el resultado esperado sería este:
libandroid_runtime.so: objeto compartido LSB ELF de 32 bits, ARM, versión 1 (SYSV), vinculado dinámicamente, despojado
Una vez más, observe que su ELF de 32 bits, compilado en forma cruzada con ARM y es una biblioteca compartida.
La clave para la compilación cruzada del host se puede encontrar en la fuente de AOSP, es decir, la compilación de Gingerbread originalmente tenía el requisito de estar construida en un sistema host de 64 bits, aquí está el enlace del grupo de noticias al que se refiere cómo parchear los scripts para que se compile en un host de 32 bits que tiene dos parches, que se encuentran aquí, para build/core.mk y build/main.mk (combinado) en la revisión Gerrit de AOSP.
Como resultado posterior, este parche llegó a los scripts de compilación de ICS en los que tuve el privilegio de compilar ICS en una plataforma de 32 bits que tardó 3 días en compilarse (era un puerto de ICS para Zte Blade). Ahora, los requisitos aumentan, hacer definitivamente necesita un host de 64 bits para permitir la compilación cruzada de la construcción de AOSP desde ICS hacia arriba 🙂
Originalmente, Android se escribió solo para procesadores de 32 bits: y específicamente, procesadores ARM de 32 bits. Más tarde, Intel y MIPS invirtieron mucho en hacer que Android también fuera compatible con sus arquitecturas, pero todavía solo procesadores de 32 bits. Pudieron hacer esto sin (muchos) problemas de compatibilidad, porque la mayoría de las aplicaciones no se envían como binarios. Escritos en Java, en su lugar se envían como bytecode, que un máquina virtual en el teléfono se compila con la arquitectura del teléfono cuando se ejecuta la aplicación. Algunas aplicaciones incluyen nativo componentes, que se envían como binarios. Esto se hace para hacer que algunos tipos de aplicaciones sean más rápidas (en particular, los juegos) o para permitir que la aplicación acceda a bibliotecas C que no están disponibles en Java. Esas aplicaciones pueden incluir más de un binario para las partes del código nativo, para permitirles ejecutarse en diferentes arquitecturas. Aun así, la mayoría de las aplicaciones son solo de Java, por lo que simplemente funcionan en cualquier arquitectura.
Todo lo anterior era cierto en el momento en que se escribió esta pregunta (y la mayoría de las otras respuestas), pero ya no. Lollipop introdujo soporte para los nuevos procesadores ARM de 64 bits (ARMv8) así como para los procesadores x86_64 de Intel y AMD, lo que significa que Android ahora admite procesadores de 32 y 64 bits. El Nexus 9 fue el primer dispositivo Android insignia de 64 bits. Además de dar acceso a nuevas extensiones de conjuntos de instrucciones, la compatibilidad con 64 bits significa que las aplicaciones pueden usar más de 4 GB de RAM. La mayoría de las aplicaciones no necesitarán tanto, pero los juegos de alta gama y el software de creación de fotos / videos ciertamente pueden usarlo: empujando a Android para que sea una plataforma para juegos con calidad de consola (incluidos los juegos de realidad virtual) y para crear contenido. Las aplicaciones Java no necesitan actualizarse para aprovechar esto, porque la máquina virtual siempre las compila en la arquitectura del teléfono, pero las aplicaciones con código nativo sí lo harán.
Debido a que ARMv8 es compatible con versiones anteriores con código de 32 bits (de la misma manera que x86_64 aún puede ejecutar código x86), incluso las aplicaciones que incluyen código nativo para procesadores de 32 bits aún pueden ejecutarse en Android de 64 bits. Por lo tanto, una aplicación solo debe compilarse para 64 bits si contiene código nativo y quiere aprovechar el límite de RAM más alto o las nuevas características de la arquitectura.
Todos los chips ARM son actualmente de 32 bits. Debido a esto, Android actualmente ejecuta todo el código en un entorno de 32 bits.
Los procesadores de 64 bits se lanzarán en 2014.