En el ámbito de los conjuntos de chips ARM, que es el factor común, toda la pila de Android, desde el núcleo casi idéntico basado en Linux, son, de hecho, de 32 bits, compilados de forma cruzada desde, por lo general, 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 construir y compilar de forma cruzada Android es Ubuntu .
La biblioteca de tiempo de ejecución de Android (medios de comunicación, gráficos, sistema de archivos, por nombrar sólo algunos) también son de 32 bits, pero cuando llegamos a la capa de la dalvikvm, entonces el número de bits se vuelve irrelevante, ya que es en este punto, las apks que vienen de la Google Play Store son bytecode nativo (Un "subproducto" de código Java generado compilado en un bytecode portátil) que se dirige a la DalvikVM (Máquina Virtual) que a su vez interpreta y traduce el bytecode dirigido al conjunto de instrucciones ARM crudo.
Froyo fue el último Android que permitió la compilación bajo un entorno alojado de 32 bits en el que se compiló de forma cruzada apuntando al chipset ARM.
Gingerbread fue el primero de los "futuros" Android, por aquel entonces hace unos tres años, que introdujo el requisito de utilizar un entorno alojado de 64 bits en el que se construyó. Hubo muchos hacks para conseguir que Gingerbread se construyera en un entorno alojado de 32 bits.
ICS y JB, y hacia arriba ahora definitivamente requiere un entorno de 64 bits para acelerar la compilación y para reducir el tiempo de entrega en la construcción.
Así que para resumir, lo que se ve en la Play Store no tiene ninguna relación con el uso de 32bit o 64bit y por lo tanto es irrelevante.
Nota al margen: Típica distribución de Linux de 16GB de RAM/Quad core/64bit, el tiempo que se tarda en construir ICS desde cero, toma 30 minutos como máximo, si esta fuera una distribución de Linux de 32bit, habría tomado más tiempo, de hecho, puede causar un colapso de la CPU ya que simplemente, no hay suficiente poder de procesamiento para batir y arrancar el código compilado cruzado, que es ¡un proceso muy exigente y agotador!
Prueba de ello.
Introduzca cualquier binario nativo de ARM que se encuentre en /system/bin o /system/xbin por ejemplo, /system/bin/dalvikvm , se trata del binario Dalvik VM que es responsable de las capas superiores de Java y de los APK.
Ahora, examine el binario emitiendo este comando: file dalvikvm que da un resumen del tipo de archivo que es, la salida esperada sería esta:
dalvikvm: Ejecutable ELF de 32 bits LSB, ARM, versión 1 (SYSV), enlazado dinámicamente (utiliza librerías compartidas), despojado
Fíjate en la referencia a ELF de 32 bits, y se compila de forma cruzada a ARM y es un ejecutable binario.
Bien, continuando, vamos a inspeccionar una biblioteca compartida nativa que se encuentra en /system/lib por ejemplo, /system/lib/libandroid_runtime.so , ahora emite 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), enlazado dinámicamente, despojado
De nuevo, fíjate en que es ELF de 32 bits, compilado de forma cruzada para ARM y es una biblioteca compartida.
La clave de la compilación cruzada del host se puede encontrar en la fuente de AOSP, es decir, Gingerbread build originalmente tenía un requisito para ser construido en un sistema host de 64 bits, aquí está el grupo de noticias enlace refiriéndose a cómo parchear los scripts para que se construyan en 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 de Gerrit de la AOSP.
Como resultado posterior, este parche había llegado 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 construirse ( era un port de ICS para el Zte Blade ). Ahora, los requisitos son mayores, usted hacer definitivamente necesita 64 bits de acogida para permitir la compilación cruzada de la construcción de AOSP de ICS hacia arriba :)
