En el ámbito de los conjuntos de chips ARM, que es el factor común, toda la pila de Android, desde el kernel casi idéntico basado en Linux, es de hecho, 32 bits, compilada cruzada desde un entorno host de 32 bits / 64 bits, el entorno host Suele ser una de las distribuciones de Linux. La distribución recomendada, por parte de Google, para construir y compilar Android de forma cruzada es Ubuntu .
La biblioteca de tiempo de ejecución de Android (medios, gráficos, sistema de archivos, por nombrar solo algunos) también tiene 32 bits, pero a medida que llegamos a la capa del dalvikvm, el número de bits se vuelve irrelevante, ya que en este punto, los apks vienen de Google Play Store son bytecode nativos (un "subproducto" del código Java generado compilado en un bytecode portátil) que se dirige a DalvikVM (Máquina virtual), que a su vez interpreta y traduce el bytecode dirigido 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 compiló de forma cruzada con el chipset ARM.
Gingerbread fue el primero de Android "futuro", en aquel entonces, alrededor de hace tres años, que introdujo el requisito de usar un entorno alojado de 64 bits en el que fue construido. Hubo muchos hacks para que Gingerbread se construyera en un entorno alojado de 32 bits.
ICS y JB, y hacia arriba ahora definitivamente requieren un entorno de 64 bits para acelerar la compilación y reducir el tiempo de respuesta en la construcción.
En resumen, lo que ves en Play Store no tiene relación con si se usan 32 bits o 64 bits y, por lo tanto, es irrelevante.
Nota al margen: distribución típica de 16 GB de RAM / Quad core / 64 bits de Linux, el tiempo que lleva construir ICS desde cero, toma 30 minutos como máximo, si se tratara de una distribución de Linux de 32 bits, de hecho, hubiera tardado más, de hecho, podría causar una fusión de la CPU ya que simplemente no hay suficiente potencia de procesamiento para producir y generar código compilado cruzado, ¡lo cual es un proceso muy exigente y exigente!
Prueba de esto.
Obtenga cualquier binario ARM nativo que se encuentre /system/bino /system/xbin, por ejemplo, /system/bin/dalvikvmeste es el binario Dalvik VM que es responsable de las capas superiores de Java y APK.
Ahora, examine el binario emitiendo este comando: file dalvikvmque proporciona un resumen del tipo de archivo que es, el resultado esperado sería este:
dalvikvm: ELF ejecutable LSB de 32 bits, ARM, versión 1 (SYSV), vinculado dinámicamente (usa libs compartidas), despojado
Observe la referencia a ELF de 32 bits, y se compila de forma cruzada a ARM y es un ejecutable binario.
Bien, continuando, inspeccionemos una biblioteca compartida nativa encontrada en /system/lib, por ejemplo /system/lib/libandroid_runtime.so, ahora problema file libandroid_runtime.so, el resultado esperado sería este:
libandroid_runtime.so: objeto compartido ELF de 32 bits LSB, ARM, versión 1 (SYSV), vinculado dinámicamente, despojado
Una vez más, tenga en cuenta que es un ELF de 32 bits, se compila de forma cruzada con ARM y es una biblioteca compartida.
La clave para la compilación cruzada del host se puede encontrar en la fuente AOSP, es decir, la compilación de Gingerbread originalmente tenía un requisito para construirse en un sistema host de 64 bits, aquí está el enlace del grupo de noticias que se refiere a cómo parchear los scripts para construirlo. Host de 32 bits que tiene dos parches, que se encuentran aquí, para build/core.mky build/main.mk( combinados ) en la revisión de 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 se intensificaron, que no necesitan definitivamente anfitrión de 64 bits para permitir la compilación cruzada de la construcción de la ICS AOSP hacia arriba :)
Originalmente, Android fue escrito 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 admitiera sus arquitecturas, pero 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 archivos binarios. Escritos en Java, en su lugar se envían como bytecode , que una máquina virtual en el teléfono compila a la arquitectura del teléfono cuando se ejecuta la aplicación. Algunas aplicaciones incluyen nativascomponentes, que se envían como un binario. Esto se hace para acelerar algunos tipos de aplicaciones (particularmente 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 permitir que se ejecuten en diferentes arquitecturas. Aun así, la mayoría de las aplicaciones son solo de Java, por lo que simplemente funcionan en cualquier arquitectura.
Lo anterior era todo cierto en el momento en que esta pregunta (y la mayoría de las otras respuestas) se escribió, pero ya no. Lollipop presentó 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 bits y de 64 bits. El Nexus 9 fue el primer dispositivo Android emblemático de 64 bits. Además de dar acceso a nuevas extensiones de conjunto de instrucciones, el soporte de 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 a ser una plataforma para juegos con calidad de consola (incluidos juegos de realidad virtual) y para crear contenido. Las aplicaciones Java no necesitan ser actualizadas para aprovechar esto, porque la máquina virtual siempre las compila a la arquitectura del teléfono, pero las aplicaciones con código nativo lo harán.
Debido a que ARMv8 es compatible con versiones anteriores de 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 necesita 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.
fuente
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 .
fuente
Tampoco en realidad. Android es un sistema operativo basado en VM Dalvik, y Google Play aloja aplicaciones Dalvik. La propia Dalvik VM, al igual que Java VM, siempre tiene 32 bits, independientemente del bit de la máquina física.
Como sospechaba, las aplicaciones que se envían con binarios nativos y aplicaciones NDK deben enviarse con binarios compilados para cada arquitectura en la que se pretende ejecutar. La arquitectura más común en la que se ejecuta Android es ARM de 32 bits; Sin embargo, también hay dispositivos que se ejecutan en x86 y MIPS.
fuente
Solo estoy adivinando, pero creo que esto también lo explica simplemente. Depende del dispositivo que esté utilizando, hay cuatro tipos de sistemas operativos que son ARM, ARM 64, X84 y X84_64. El ARM es la popular plataforma de 32 bits, ARM 64 también es la plataforma popular pero de 64 bits, X84 es la plataforma poco común y se usa en Zenfones, al igual que X84_64 es poco común y se usa en los emuladores de Android. Obtuve esta información del sistema operativo en Open Gapps
fuente