Por que usar o código armeabi-v7a sobre o código armeabi?

No meu projeto atual, uso vários arquivos .so. Eles estão localizados na pasta armeabi e armeabi-v7a. Infelizmente, um dos arquivos .so tem 6 MB e preciso reduzir o tamanho do arquivo. Em vez de ter um arquivo APK gordo, eu gostaria de usar apenas os arquivos armeabi e remover a pasta armeabi-v7a.

De acordo com a documentação do NDK, o código armeabi-v7a é um código armeabi estendido que pode conter instruções extras da CPU. Tudo isso vai além da minha experiência, mas questiono por que alguém gostaria de ter os códigos armeabi-v7a e armeabi. Deve haver uma boa razão para ter os dois, certo?

Nos meus dispositivos de teste, tudo isso parece funcionar bem. Estes possuem CPUs ARM v7. É seguro assumir que tudo funciona agora?

Depende do que seu código nativo faz, mas a v7a tem suporte para operações de ponto flutuante de hardware, o que faz uma enorme diferença. O armeabi funcionará bem em todos os dispositivos, mas será muito mais lento e não aproveitará os recursos de CPU dos dispositivos mais recentes. Faça alguns benchmarks para seu aplicativo específico, mas remover os binários armeabi-v7a geralmente não é uma boa ideia. Se você precisar reduzir o tamanho, convém ter dois aplicativos separados para dispositivos mais antigos (armeabi) e mais novos (armeabi-v7a).

EABI = Interface Binária de Aplicativo Incorporado. São essas especificações às quais um executável deve estar em conformidade para ser executado em um ambiente de execução específico. Ele também especifica vários aspectos de compilação e vinculação necessários para a interoperação entre cadeias de ferramentas usadas para a arquitetura ARM. Nesse contexto, quando falamos sobre armeabi , falamos sobre arquitetura ARM e SO GNU / Linux. O Android segue o pequeno ARM GNU / Linux ABI.

O aplicativo armeabi será executado no ARMv5 (por exemplo, ARM9) e ARMv6 (por exemplo, ARM11). Você pode usar o hardware de ponto flutuante se criar seu aplicativo usando opções apropriadas de GCC, como -mfpu = vfpv3 -mfloat-abi = softfp, que instrui o compilador a gerar instruções de ponto flutuante para o hardware VFP e habilita as convenções de chamada de flutuação suave. O armeabi não suporta convenções de chamada de flutuação (significa que os registros FP não são usados ​​para conter argumentos para uma função), mas as operações FP no HW ainda são suportadas.

O aplicativo armeabi-v7a será executado em dispositivos Cortex A # como Cortex A8, A9 e A15. Ele suporta processadores com vários núcleos e -mfloat-abi = hard . Portanto, se você construir seu aplicativo usando -mfloat-abi = hard , muitas de suas chamadas de função serão mais rápidas.

Em vez de ter um arquivo APK gordo, eu gostaria de usar apenas os arquivos armeabi e remover a pasta armeabi-v7a.

O oposto é uma estratégia muito melhor. Se você tiver minSdkVersion14 anos e fizer o upload do seu apk para a Play Store, notará que suportará o mesmo número de dispositivos, com armeabiou sem suporte . Portanto, não há dispositivos com Android 4 ou superior que possam se beneficiar armeabi.

Provavelmente é por isso que o Android NDK nem suporta armeabimais, conforme a revisão r17b. [ fonte ]