¿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?

2 Solutions collect form web for “¿Por qué usar el código armeabi-v7a sobre el código armeabi?”

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.

  • Gcc en el brazo / android
  • ¿Cómo implementar mbtowc para android? (O, idealmente, ¿cómo no hacerlo?)
  • Acelerando las operaciones de punto flotante (Android ARMv6)
  • ¿Hay una tarjeta PCI Android?
  • Ejemplo de Android BSP (fuente) para ARM
  • ¿Cómo se escribe el código nativo android para ARM en x86?
  • Compilador JIT de Dalvik en Linux X86 o Mac build
  • ¿Cómo puedo optimizar una multiplicación-vector-multiplicación 4D con ARM NEON?
  • Android Studio - ¿Cómo puedo hacer un AVD con ARM en lugar de HAXM?
  • Cómo construir una biblioteca compartida sin JNI en Android?
  • Android ARMv6 / v7 y VFP / NEON
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.