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/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 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.mk
y 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 :)