Desde que el año pasado Apple lanzara el nuevo iOS 7, compatible con procesadores de 64 bits, se comenzó a hablar sobre el lanzamiento de una nueva versión de Android que fuera compatible también con procesadores de 64 bits, y de lo imprescindible que era el lanzamiento de dicha versión de firmware. Sin embargo, han pasado muchos meses, y Android todavía no es compatible con procesadores de 64 bits. No obstante, el nuevo Android 4.5 podría cambiar eso.
Al menos, es lo que parece por las posibles nuevas API de Android que se lanzarían con la nueva versión. Hay que decir inicialmente que estos nuevos datos provienen precisamente del proyecto AOSP, que suele contar con las novedades que se lanzarían en Android antes que cualquier otro. Las últimas novedades referentes a este proyecto hablan de la llegada de los 64 bits a Android-L. Android L sería en realidad la nueva versión del sistema operativo. Como sabéis, las diferentes iteraciones de Android se van nombre por orden alfabético, y la letra siguiente a la K de KitKat, es la letra L.
Parece que se le va a cambiar el nombre a las API. En lugar de nombrarlas con un número, ahora podría nombrárselas con una letra. Android L sería la API de la nueva versión Android 4.5.
Los nuevos datos confirman que la nueva versión sería compatible con procesadores de 64 bits. Además, esto parecía bastante probable, dado que compañías como Samsung ya estaban trabajando en smartphones con procesador de 64 bits, que podrían ser lanzados al mercado próximamente.
Fuente: AOSP.
Compatibilidad de 64 bits: claves técnicas y beneficios
El salto a arquitecturas ARMv8 y x86_64 permite más registros, instrucciones modernas y mejor gestión de memoria. No implica el doble de velocidad, pero sí ganancias de rendimiento en muchos escenarios gracias a anchos de datos mayores y llamadas de sistema más eficientes.
Un punto crítico es el direccionamiento de memoria. Con 64 bits se elimina el límite práctico cercano a los 3 GB que afecta a 32 bits, abriendo la puerta a dispositivos con más RAM y multitarea más holgada.
Como contrapartida, los punteros ocupan más, y algunas apps pueden consumir más memoria si no están optimizadas. Incluso pueden correr más lentas si el código nativo no se adapta correctamente.
En cualquier caso, los procesadores de 64 bits mantienen retrocompatibilidad y son capaces de ejecutar apps de 32 bits, evitando romper el ecosistema actual mientras los desarrolladores migran.
Nuevas API, Android L y cambios de nomenclatura
Las referencias en AOSP apuntan a un conjunto de APIs que mapean explícitamente la ABI arm64-v8a y x86_64 (como en el ZTE Apollo), y a una nomenclatura por letras para agrupar familias de funciones del sistema. Esto refuerza la idea de un Android 4.5/Android L con soporte nativo de 64 bits en kernel y runtime.
El runtime (Dalvik/ART) debe estar optimizado para 64 bits a fin de que las apps en Java/Kotlin ganen rendimiento sin cambios de código, mientras que el código nativo (NDK) requiere binarios específicos.
Fabricantes y hardware: Google, Samsung, Qualcomm e Intel
Los grandes actores ya han señalado el camino. Samsung anunció teléfonos con 64 bits; Qualcomm tiene SoC con esa arquitectura; Intel trabaja sobre Android x86_64 y distribuyó builds a OEMs para acelerar el soporte. Todos comparten una base ARMv8 o x86_64 con mejoras sustanciales en seguridad y eficiencia.
Que hardware y software avancen a la vez es clave: sin Android oficial de 64 bits, el impacto real de estos chips sería limitado.
Qué exige Google Play y cómo preparar tu app
Google Play exige que las apps con código nativo incluyan librerías de 64 bits además de las de 32. Para verificarlo, inspecciona tu APK: debe contener carpetas lib/arm64-v8a y/o lib/x86_64 en paralelo a armeabi-v7a o x86.
Usa Android Studio: Build > Analyze APK… o una comprobación por línea de comandos (p. ej., con zipinfo | grep .so) para confirmar la presencia de binarios de 64 bits. Si faltan, ajusta tu compilación.
Compilación: en Gradle añade ABIs en ndk.abiFilters; con CMake, pasa -DANDROID_ABI=arm64-v8a o x86_64; con ndk-build, amplía APP_ABI. Considera Android App Bundle para minimizar el impacto en tamaño.
Portabilidad: revisa el manejo de punteros (usa uintptr_t/intptr_t, ptrdiff_t), evita supuestos de tamaños fijos, activa avisos como -Werror=pointer-to-int-cast e intercambia jint por jlong en JNI cuando corresponda. Ajusta formatos con macros PRI/SCN y usa literales como 1ULL si necesitas 64 bits explícitos.
Herramientas y SDKs: actualiza SoLoader a versiones modernas, emplea OpenSSL reciente compatible con extensiones ARM, y revisa ofuscadores ante cambios como BTI. Si usas RenderScript antiguo, elimina artefactos .bc y recompila con toolchains actuales.
Game engines: motores como Unity, Unreal o Cocos soportan 64 bits; en Unity, selecciona IL2CPP y ARM64 en la arquitectura objetivo. Prueba en hardware de solo 64 bits o en Android Emulator con imágenes recientes.
Contexto de mercado y necesidad real
El debate sobre si los usuarios “necesitan” 64 bits suele confundirse con marketing. Hoy, muchos pueden llamar, navegar y usar GPS en equipos modestos; sin embargo, la industria empuja a 64 bits para garantizar futuro, como el Nexus 9, habilitar más memoria, mejorar seguridad y ofrecer un margen de rendimiento para apps exigentes.
Sea cual sea el ritmo exacto del despliegue, los indicios en AOSP, el trabajo de fabricantes de chips y los requisitos de Play pintan un escenario en el que Android 4.5/Android L se posiciona como el punto de inflexión hacia una plataforma plenamente preparada para 64 bits, manteniendo compatibilidad y abriendo puertas a nuevos casos de uso.
