¿Por qué usar el código armeabi-v7a sobre el código armeabi?

En mi proyecto actual uso varios archivos .so. Estos se encuentran en la carpeta armeabi y armeabi-v7a. Desafortunadamente uno de los archivos. So es un 6 MB y necesito reducir el tamaño del archivo. En lugar de tener un archivo APK graso, me gustaría usar sólo los archivos armeabi y eliminar la carpeta armeabi-v7a.

De acuerdo con la documentación de NDK, el código armeabi-v7a es un código armeabi extendido que puede contener instrucciones adicionales de la CPU. Todo esto va más allá de mi experiencia, pero me pregunto por qué uno quisiera tener el código armeabi-v7a y armeabi. Debe haber una buena razón para tener ambos, ¿verdad?

En mis dispositivos de prueba todo esto parece funcionar bien. Estos tienen CPU ARM v7. ¿Es seguro asumir que todo funciona ahora?

Depende de lo que hace tu código nativo, pero v7a tiene soporte para operaciones de punto flotante de hardware, lo que hace una gran diferencia. Armeabi funcionará bien en todos los dispositivos, pero será mucho más lento, y no se aprovechará de las capacidades de CPU de los dispositivos más nuevos. No tome algunos puntos de referencia para su aplicación en particular, pero la eliminación de los binarios armeabi-v7a generalmente no es una buena idea. Si necesita reducir el tamaño, es posible que desee tener dos apks separados para los dispositivos más antiguos (armeabi) y los más nuevos (armeabi-v7a).

EABI = Interfaz binaria de aplicación incorporada. Son las especificaciones a las que debe ajustarse un ejecutable para ejecutarse en un entorno de ejecución específico. También especifica varios aspectos de compilación y vinculación necesarios para la interoperación entre los toolchains utilizados para la arquitectura ARM. En este contexto cuando hablamos de armeabi hablamos de arquitectura ARM y GNU / Linux OS. Android sigue el poco-endian ARM GNU / Linux ABI.

La aplicación armeabi se ejecutará en ARMv5 (por ejemplo, ARM9) y ARMv6 (por ejemplo ARM11). Puede utilizar el hardware de punto flotante si crea su aplicación utilizando opciones adecuadas de GCC como -mfpu = vfpv3 -mfloat-abi = softfp que le dice al compilador que genere instrucciones de coma flotante para hardware VFP y active las convenciones de llamada de flotación suave. Armeabi no admite convenios de llamada de hard-float (significa que los registros FP no se utilizan para contener argumentos para una función), pero las operaciones FP en HW siguen siendo compatibles.

La aplicación armeabi-v7a se ejecutará en dispositivos Cortex A # como Cortex A8, A9 y A15. Es compatible con procesadores multi-núcleo y soporta -mfloat-abi = duro . Por lo tanto, si crea su aplicación usando -mfloat-abi = hard , muchas de sus llamadas de función serán más rápidas.

  • ¿Cómo definir y activar mi propio softirq nuevo en el kernel linux?
  • ¿Consigo un bono de rendimiento si intento utilizar comandos de ensamblador de matemáticas de brazo en lugar de c
  • Lista de código nativo soportado de teléfonos Android
  • ¿Cuál es el uso de la imagen del sistema ARM EABI v7a en android?
  • Advertencia de ARM: swp {b} use está obsoleto para esta arquitectura
  • ¿Es posible ejecutar un binario de brazo nativo en un teléfono Android no enraizado?
  • Compilación cruzada de GCC con newlib para ARM: cómo especificar opciones de GCC como -march?
  • NDK: cómo construir una lib, por lo que la aplicación puede trabajar en brazo (s), x86, etc?
  • SIGILL en el código Android NDK
  • Prueba NEON-optimizado cv :: threshold () en el dispositivo móvil
  • ¿Es seguro soportar sólo armeabi-v7a para Android 4 o superior?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.