146

In my current project I make use of multiple .so files. These are located at the armeabi and armeabi-v7a folder. Unfortunately one of the .so files is a 6MB and I need to reduce file size. Instead of having a fat APK file, I would like to use just the armeabi files and remove the armeabi-v7a folder.

According to the NDK documentation, armeabi-v7a code is extended armeabi code which can contain extra CPU instructions. This all goes beyond my expertise, but I question why one would like to have both armeabi-v7a and armeabi code. There must be a good reason to have both, right?

On my test devices this all seem to work fine. These have ARM v7 CPU's. Is it safe to assume that everything works now?

Sam R.
  • 16,027
  • 12
  • 69
  • 122
PaulT
  • 1,797
  • 2
  • 12
  • 13
  • 2
    You might want to give this blogpost a read now. It is thorough and up-to-date: https://androidbycode.wordpress.com/tag/armeabi-v7a/ – IgorGanapolsky Aug 08 '16 at 13:37
  • 2
    And now the doc says: `armeabi is deprecated in NDK r16. Removed in NDK r17. No hard float.` – amrezzd Aug 15 '18 at 05:02
  • 1
    For those coming later, take a look at [here](https://stackoverflow.com/questions/28926101/is-it-safe-to-support-only-armeabi-v7a-for-android-4-and-above). – amrezzd Aug 15 '18 at 05:04

3 Answers3

164

Depends on what your native code does, but v7a has support for hardware floating point operations, which makes a huge difference. armeabi will work fine on all devices, but will be a lot slower, and won't take advantage of newer devices' CPU capabilities. Do take some benchmarks for your particular application, but removing the armeabi-v7a binaries is generally not a good idea. If you need to reduce size, you might want to have two separate apks for older (armeabi) and newer (armeabi-v7a) devices.

Update 2012-09; Google's Play Store finally has support for uploading different APKs (each targeting a different CPU architecture), with the so-called "multiple APKs" feature:
https://developer.android.com/google/play/publishing/multiple-apks

Where maybe each APK needs to have a different version code (even if they all are actually the same version, just with different CPU target).

But Update 2023; Google recommends creating "App bundle" instead of using "multiple APKs" feature:
https://developer.android.com/guide/app-bundle

Where for "App bundle", the Play store can automatically bring down the download size, based on the device which's downloading.

Top-Master
  • 7,611
  • 5
  • 39
  • 71
Nikolay Elenkov
  • 52,576
  • 10
  • 84
  • 84
  • Thanks for your clear reply. It will be a good idea to do benchmarking as well of splitting the application in 2 APK files. The latter is actually a very good idea! Many thanks! – PaulT Aug 16 '11 at 20:09
  • 2
    Where Can I find difference between the both ABI ? I'm very instersted to understand real differences... – webshaker Jan 15 '12 at 18:33
  • 8
    ARM manuals? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344c/Cacciced.html – Nikolay Elenkov Jan 16 '12 at 02:33
  • Not really. You are limited by Google Play used to differentiate APKs (screen size, target version, etc). There are some apps that have their native libs as a 'plugin' of sorts, but you need to download another APK for you platform. Check MX Player for example. – Nikolay Elenkov Jul 13 '12 at 14:31
  • Long overdue. They seem to still recommend single APK when possible though. – Nikolay Elenkov Sep 20 '12 at 01:53
  • Is the phrase "separate apks for older (armeabi) and newer (armeabi-v7a) devices" the same as "separate apks for older (armv5) and newer (armv7a) devices"? – trusktr Jan 11 '13 at 08:45
  • Kind of. I *think* the only released Android devices before armv7a are all armv5 (G1, Magic, etc.). – Nikolay Elenkov Jan 11 '13 at 09:05
  • The older devices are actually ARMv6, but Android used ARMv5TE as the baseline. There's very little reason to build for pre-v7 hardware today. – fadden Aug 01 '13 at 23:30
60

EABI = Embedded Application Binary Interface. It is such specifications to which an executable must conform in order to execute in a specific execution environment. It also specifies various aspects of compilation and linkage required for interoperation between toolchains used for the ARM Architecture. In this context when we speak about armeabi we speak about ARM architecture and GNU/Linux OS. Android follows the little-endian ARM GNU/Linux ABI.

armeabi application will run on ARMv5 (e.g. ARM9) and ARMv6 (e.g. ARM11). You may use Floating Point hardware if you build your application using proper GCC options like -mfpu=vfpv3 -mfloat-abi=softfp which tells compiler to generate floating point instructions for VFP hardware and enables the soft-float calling conventions. armeabi doesn't support hard-float calling conventions (it means FP registers are not used to contain arguments for a function), but FP operations in HW are still supported.

armeabi-v7a application will run on Cortex A# devices like Cortex A8, A9, and A15. It supports multi-core processors and it supports -mfloat-abi=hard. So, if you build your application using -mfloat-abi=hard, many of your function calls will be faster.

psihodelia
  • 29,566
  • 35
  • 108
  • 157
  • 1
    According to https://developer.android.com/ndk/guides/abis.html: `The armeabi-v7a ABI uses the -mfloat-abi=softfp switch`. So what do you mean by **supports -mfloat-abi=hard**? – IgorGanapolsky Aug 08 '16 at 13:06
9

Instead of having a fat APK file, I would like to use just the armeabi files and remove the armeabi-v7a folder.

The opposite is a much better strategy. If you have minSdkVersion to 14 and upload your apk to the play store, you'll notice you'll support the same number of devices whether you support armeabi or not. Therefore, there are no devices with Android 4 or higher which would benefit from armeabi at all.

This is probably why the Android NDK doesn't even support armeabi anymore as per revision r17b. [source]

mmBs
  • 8,421
  • 6
  • 38
  • 46
Cristan
  • 12,083
  • 7
  • 65
  • 69