Why Use Armeabi-V7A Code Over Armeabi Code

Why use armeabi-v7a code over armeabi code?

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.

What does ABIs: armeabi-v7a in the android version detail mean? please provide the internal details of how this is used?

ARM is a type of instruction set for CPUs usually used on mobile devices.

armeabi stands for ARM embedded application binary interface, it means the image that the android is running is built with EABI support. armeabi-v7a code is extended armeabi code which can contain extra CPU instructions, and have support for hardware floating point operations.

You'll find a more detailed answer at: Why use armeabi-v7a code over armeabi code? link.

How to use armeabi .so-files on other architectures?

Finally I solved the problem! After days of desperation, I got it working by downgrading Gradle from 7.1.2 to 3.2.0.

The old Gradle version logs:

Unable to strip library '.....\app\build\intermediates\transforms\mergeJniLibs\debug\0\lib\armeabi\lib.so' due to missing strip tool for ABI 'ARMEABI'. Packaging it as is.

And then all devices, also 64-bit-devices, pick the "armeabi"-libraries.

By setting android.defaultConfig.ndk { abiFilters 'armeabi' } in app\build.gradle, it also works with Gradle 7.

Difference between armeabi and armeabi-v7a

You definitely can run armeabi shared library on v7, and you can call its exported functions from another module. So, to be on the safe side, I would create a separate .so file from you Pascal code, sticking to armeabi (maybe with some C/C++ wrappers), and use this shared library with both your armeabi and armeabi-v7a libraries. The easiest way to load everything in correct order is to use

System.loadLibrary("pascal"); // armeabi
System.loadLibrary("c++"); // the platform will choose armeabi or armeabi-v7a

What is armeabi and why they use it?

Android devices have CPUs. Many of those CPUs are based on the ARM architecture, while some are based on x86, and a few others are based on other stuff like MIPS.

Some Android apps use the Native Development Kit (NDK) to create C/C++ code to link into their app. C/C++ code needs to be compiled for a specific CPU architecture. The NDK places the version of the C/C++ code compiled for each architecture into an architecture-specific directory. One of those directories is armeabi/, which is for a generic ARM CPU. There is also armeabi-v7/ (for an ARM v7-compatible CPU), x86/ (for x86 CPUs), etc.

Will an app built with only armeabi run on armeabi-v7a devices?

According to the Xamarin Android documentation, armeabi code will crash in unexpected ways on a multi-core armeavi-v7 device.

http://docs.xamarin.com/guides/android/advanced_topics/cpu_architecture

Section 1.1

Note: Xamarin.Android’s armeabi code is not thread safe and should not
be used on multi-CPU armeabi-v7a devices (described below). Using
aremabi code on a single-core armeabi-v7a device is safe.

The reason that Xamarin Android make it a requirement to include armeabi-v7a has to do with thread safe memory access. Put simply the armeabi instruction set lacks the instructions necessary to safely lock memory on SMP devices.

The most thorough discussion of the issue can be found in this bug report: https://bugzilla.xamarin.com/show_bug.cgi?id=7013

Jonathan Pryor 2012-09-20 11:41:45 EDT

As far as I can determine, it is (nearly) IMPOSSIBLE to SAFELY use an armeabi
library on a SMP armeabi-v7a device. This is because armeabi lacks the CPU
instructions necessary to safely lock data on SMP devices, so if the armeabi
library contains data that must be protected against access from multiple
threads, it's busted, and libmonodroid.so is such a library. This may be
fixable by creating a libmonodroid.so which dynamically determines the runtime
CPU, allowing it to use either armeabi or armeabi-v7a lock instructions
accordingly, but this has not been done yet, and the implementation timeframe
is unknown.

Thus, if your app will be running on SMP hardware, you should include the
armeabi-v7a runtime with your app. This can be done in the Project Options
dialog.

These crashes are rare but catastrophic and very hard to debug as you experience random memory corruption and segmentation faults.

I was able to reproduce the issue reliably on a Galaxy S3. Some example code that demonstrates the crash is in this bug report: https://bugzilla.xamarin.com/show_bug.cgi?id=7167

---

It's unknown whether or not this bug affects other NDK applications on Android. But it definitely affects Xamarin Android.

---

Related Topics