¿Por qué las aplicaciones armv8a no pueden ejecutarse en armv7a?

Conceptos básicos

Aplicaciones creadas íntegramente a partir de código Java o Kotlin, incluidas todas las bibliotecas y SDK que utilizan, no me importa sobre cuáles de armv7a y armv8a admite un dispositivo. Sin embargo, bastantes aplicaciones incluyen "código nativo", o "código máquina", normalmente compilado a partir de código C o C++ mediante el kit de desarrollo nativo de Android ("NDK").

Un determinado fragmento de código máquina puede ser de 32 bits (armv7a) o de 64 bits (armv8a). En no puede ser ambas cosas.

Ejecución de código nativo

Las aplicaciones que admiten tanto armv7a como armv8a tienen dos juegos de código máquina incluido en sus archivos APK:

• Un juego para armv7a
• Un juego para armv8a

Tu dispositivo armv7a puede ejecutar felizmente el código destinado a él. Puede entenderlo, y tiene las bibliotecas y otro software que necesita para ejecutarlo. No puede entender el código armv8a en absoluto, y por lo tanto es incapaz de ejecutarlo. Las aplicaciones que sólo son compatibles con armv8a no pueden ejecutarse, por lo que Android impide su instalación.

Próximas complejidades

La arquitectura ARMv9 empezará a aparecer en dispositivos Android muy pronto. El sitio Qualcomm Snapdragon 8 Gen 1 fue uno de los primeros chips v9 anunciados, en noviembre de 2021. La mayoría de los núcleos ARMv9 no pueden ejecutar código armv7a, porque no implementan ese conjunto de instrucciones de 32 bits (ni ningún otro). Ellos puede ejecutar código armv8a. Esto significa que los dispositivos con procesadores ARMv9:

• Puede ejecutar aplicaciones compatibles con armv7a y armv8a.
• Puede ejecutar aplicaciones que sólo soportan armv8a.
• No puedo ejecutar aplicaciones que sólo soportan armv7a.

Es bueno que Google haya estado exigiendo que las aplicaciones nuevas y actualizadas incluyan el código armv8a desde agosto de 2019 si incluyen cualquier código nativo.

Si el Android NDK adquiere la opción de compilar para armv9a, dicho código no se ejecutará en dispositivos armv7a o armv8a. Supongo que Google exigirá que los APK con código armv9a proporcionen también código armv8a, al menos durante unos años.

¿Por qué hay código máquina armv7a en uso?

Android tiene una historia bastante larga, y cuando empezó no se habían creado ni armv7a ni armv8a. Así que ha habido un proceso gradual de actualización del código nativo a estándares más recientes.

En más detalles En junio de 2009, el NDK original solo admitía código máquina "armeabi", que utilizaba el conjunto de instrucciones ARMv5TE. Armv7a se añadió en junio de 2010, x86 en junio de 2011 y MIPS en mayo de 2012. Armv8a, junto con x86 de 64 bits y MIPS se añadió en julio de 2014. Armeabi, MIPS y MIPS64 se eliminaron en junio de 2018.

Alguien que empiece a trabajar con Android NDK hoy en día soportaría armv7a y armv8a, o quizás sólo armv8a si sólo estuviera interesado en dispositivos más nuevos y rápidos, o si su aplicación necesitara usar lotes de la memoria.

Ha habido algunos dispositivos Android que tenían procesadores de 64 bits y un kernel Android de 64 bits, pero no tenían tiempos de ejecución Java/Kotlin de 64 bits. El que me encontré fue un modelo de 2017 del Amazon Kindle Fire HD 10, que ya está descatalogado. Lo compré para Android 5 de 64 bits, y la falta de tiempos de ejecución Java de 64 bits no fue un problema para el código nativo que necesitaba probar en el shell ADB.

La principal ventaja de los tiempos de ejecución Java/Kotlin de 64 bits es que permiten a las aplicaciones que se ejecutan en ellos acceder a más memoria. Esto solo es significativo en dispositivos con al menos 4 GB de RAM, por lo que ofrecer esos tiempos de ejecución en dispositivos con memorias más pequeñas tiene poco valor.

SoC Arm v7 => 32 bits

SoC Arm v8 => 32 bits + 64 bits ambos

Arm v7a + Arm v8a paquetes => tiene tanto Armv7a y v8a binarios de esa aplicación incluido, por lo que se instala la versión de 32 bits (Arm v7a) del paquete si el dispositivo tiene un Arm v7 SoC, la versión de 64 bits si el dispositivo tiene un Arm v8 SoC

Paquetes Arm v7a => sólo tiene binarios de 32 bits, instalables en chips Armv7 y v8

Paquetes Arm v8a => sólo tiene binarios instalables Armv8a, por lo que si el dispositivo es de 32 bits, el paquete de la aplicación simplemente no se instalará.