Armeabi and armeabi-v7a (EXT)

In the ANE if the SDK calls the so library, you need to place the so library under the ANE Android-arm/lib/armeabi (debug mode) or armeabi-v7a (release mode).

You can put an ADT code to illustrate the problem:

Whether M_configtype.equals ("apk") is a release mode
(Hascaptiveruntime () with Run-time
if ((M_configtype.equals ("apk")) | | (Hascaptiveruntime ()))
{
Destapkdirectory = "lib/armeabi-v7a/";
}
Else
{
Destapkdirectory = "lib/armeabi/";
}

And what exactly does this armeabi and armeabi-v7a mean?

What is the meaning of it?

Why is debug mode and release mode Adobe selecting a different folder?

I have an understanding of this little problem in this document.

Armeabi and ARMEABI-V7A express support for different CPU types
Armeabi refers to the so library for the general CPU of ARM, while the V7A CPU supports hardware floating point arithmetic. So Armeabi versatility, but slow, and v7a can give full play to the V7A CPU capacity, in the air packaging apk debug mode Adobe chose a versatile Armeabi mode.

Android supports the deep meaning of different CPUs
First of all, from the hardware support point of view, most of our adnroid devices are supported arm chips so far, (of course, the latest Android machine in the market now also supports several other chips such as Intel, such as Intel's latest Atom project Chip, Have gained the favor of android4.1). From the Android version to the extent of supporting arm hardware encoding:

Initially android1.6: Supports only armv4 and armv5te instruction sets.

To android2.0: Added support for arm-vfp,armv6,armv6t2 instruction set.

To android2.2: Added support for armv7-a instruction set.

So armeabi-v7a should be related to the conditions above which air is limited to support android2.2. android2.2 above can make the hardware play a bigger role.

Do I use Armeabi or armeabi-v7a in my project?
For air projects The performance problem is the biggest bottleneck, can optimize a little bit, so if the platform-side SDK or write ane when using the so library, the personal recommendations are all put under the armeabi-v7a, and not for compatibility put to Armeabi.

-eof-

In our Android apk root directory has a Libs folder, this folder contains the Armeabi and armeabi-v7a two folders, our C code compiled into the local library (various. So) will be placed in one of these two folders. What is the difference between armeabi-v7a and Armeabi, and what does it mean?
Armeabi and armeabi-v7a is the type of CPU, we know that the general mobile phone or tablet is used arm CPU (MIPS is sad to be ignored), different characteristics of the CPU, Armeabi is for the normal or old arm V5 CPU, The armeabi-v7a is an arm v7 CPU with floating-point arithmetic or advanced expansion capabilities.
The following macros can be configured in ANDROID.MK:
Target_cpu_api: = Armeabi
App_abi: = Armeabi

When you compile, there are some undefine errors linked to the dynamic library, or if your APK runtime is loaded. So dynamic library error, you might want to look at the configuration of this CPU type is wrong.
========================================================================================================
Now there are x86, in fact Armeabi, armeabi-v7a, and x86 are the three supported application binary interfaces (ABI) that can be used when compiling the NDK library:
' Armeabi ' – The default option is to create a library that targets arm* V5te-based devices. Floating-point operations with this goal use software floating-point arithmetic. Binary code created with this ABI will be able to run on all arm* devices.
' armeabi-v7a ' – Create a library that supports arm* V7-based devices and will use the hardware FPU instructions.
' x86 ' – the generated binary code can support IA-32 instruction sets that contain hardware-based floating-point operations.
==========================================================================================================
What is NEON?
Neon* is a arm* technology, mainly used in multimedia (smartphones and HDTV) applications. arm* says its technology based on the 128-bit SIMD engine –arm* cortex* (a serial extension)-provides performance at least 3 times times higher than the arm* V5 architecture, and at least twice times higher than arm* V6. For more information on this technology to learn more about NEON and other performance considerations, please visit the following URL: http://www.arm.com/products/processors/technologies/neon.php
The key idea here is that each register is "stacked" into a vector, where each register is an element and matches the data type of the other elements. On top of this, the operation executes within the pipeline, so this method is called Packed SIMD.
SSE: A NEON-like tool introduced by Intel
SSE refers to SIMD Extensions for Intel architecture (IA). Currently, intel® Atom™ supports up to SSSE3 (Supplemental SIMD Extensions 3). The sse4.x is not supported by the atom at this stage. The latter is also a 128-bit engine for packaging floating-point data. This pattern of execution begins with MMX technology. SSx is the newer technology that replaces the MMX. For more information, please refer to the "First Volume: Infrastructure" section of the Intel IA-32 and IA-64 software Developer's Manual. The URL is: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html. Currently, SSE Overview section is in section 5.5. It provides operation codes for SSE, SSE2, SSE3, and SSSE3. Note that data operations typically involve processing precision-based packaged floating-point values, and require bulk data transfer between the XMM registers or between these registers and memory. The XMM register is primarily used to replace the MMX register.

Armeabi and armeabi-v7a (EXT)