Armeabi y armeabi-v7a carpeta
Estoy trabajando en un proyecto de Android y estoy usando el NDK para llamar métodos nativos. Tengo dos librerías (archivos .so) y una se encuentra en la carpeta libs/armeabi
y la otra se encuentra en la lib libs/armeabi-v7a
lib.
Si intento ejecutar la aplicación entonces no cargará la biblioteca en la carpeta /libs/armeabi
. Si muevo el archivo de biblioteca a la carpeta libs/armeabi-v7a
, carga la biblioteca, pero después de 5 a 10 minutos se bloquea y da un error de segmentación.
- ¿Es posible ejecutar un binario de brazo nativo en un teléfono Android no enraizado?
- PÁNICO: Programa de motor emulador que falta para CPUS de 'brazo'
- ¿Es seguro construir con -fsigned-char con Android NDK?
- Gradle + ndkbuild + android studio 2.2 cómo establecer ABIs compatibles?
- Depuración del código del kernel de Linux en plataformas Android
Me preguntaba si la localización de la biblioteca (diversa carpeta) podría causar este problema.
- Compilación cruzada de GCC con newlib para ARM: cómo especificar opciones de GCC como -march?
- Qt versiones para arquitecturas mips, brazo, x86 faltan
- Lista de código nativo soportado de teléfonos Android
- Código nativo de auto-modificación en Android
- ¿Qué conocimiento / expertize se requiere para portar android a dispositivo de brazo personalizado?
- Compilador JIT de Dalvik en Linux X86 o Mac build
- ¿Hay una tarjeta PCI Android?
- ¿Consigo un bono de rendimiento si intento utilizar comandos de ensamblador de matemáticas de brazo en lugar de c
Soy nuevo en esto mismo, pero siguiendo el mismo camino … hasta donde yo sé, uno puede tener solamente una biblioteca compartida sola; Para usar varias bibliotecas, hacerlas estáticas y vincularlas a una única compartida. Por supuesto, esto supone que usted mismo está construyendo las bibliotecas 😉
Al instalar una aplicación, el servicio gestor de paquetes explorará el archivo .apk y buscará cualquier biblioteca compartida del formulario:
lib/<primary-abi>/lib<name>.so
Si se encuentra uno, se copia en $ APPDIR / lib / lib.so, donde $ APPDIR corresponde al directorio de datos específico de la aplicación.
Si no se encuentra ninguno y se define una ABI secundaria, el servicio buscará bibliotecas compartidas del formulario:
lib/<secondary-abi>/lib<name>.so
Si se encuentra algo, se copia en $ APPDIR / lib / lib.so.
Para el abi primario / secundario,
El sistema Android sabe en tiempo de ejecución que soporta ABI (s). Más precisamente, se utilizan hasta dos propiedades de sistema específicas de construcción para indicar:
-
El ABI "primario" para el dispositivo, correspondiente al código de máquina utilizado en la propia imagen del sistema.
-
Un ABI 'secundario' opcional, correspondiente a otro ABI que también está soportado por la imagen del sistema.
Por ejemplo, un dispositivo basado en ARMv5TE típico sólo definiría el ABI primario como 'armeabi' y no definiría un secundario.
Por otro lado, un dispositivo basado en ARMv7 típico definiría el ABI primario a 'armeabi-v7a' y el secundario a 'armeabi', ya que puede ejecutar binarios nativos de aplicación generados para ambos.
Este mecanismo garantiza que el mejor código de máquina para el dispositivo de destino se extraiga automáticamente del paquete en el momento de la instalación.
El cargador de la biblioteca intentará buscar las bibliotecas que mejor se adapten a la arquitectura en la que se está ejecutando. En general, debe compilar una versión de la biblioteca para cada uno de los abis que va a soportar (armeabi, armeabi-v7a, x86, mips) para que el compilador pueda optimizar correctamente.
La estructura de directorios es la forma en que Android determina qué lib se debe cargar, por lo que es fundamental que no la cambie.
- Android: ¿Cómo ajustar el margen / relleno en la preferencia?
- Buscando un buen ejemplo de usar get () con un AsyncTask en android