INSTRUCTION SET:
Processors are made of semiconductor dies, usually electronic-grade mono-crystalline silicon. They don't know English or any other human language, they understand only 0 and 1. So the designer of processor tells us in what sequence of zero's and one's we can instruct that specific processor. This numerical language of instructions is standardized as Machine Language and the set of machine instructions is called Instruction Set. A processor can act upon only specific type(s) of instruction set.
Instruction sets can be 8/16/32/64-bit (defines how many instructions a processor can process at a time), last 2 being the common one these days.
LOW LEVEL LANGUAGES:
But writing program code (instructions) directly in machine language (the executable file) is near to impossible because it will take years to write and debug a reasonably larger program (that we can write in a few hours these days). So to put programmers at ease, Assembly Language was developed, still a processor-specific language but relatively easy to understand. Code written in Assembly Language is converted into machine code by Assembler - a program written in Machine language. Both of these are called Low Level languages.
HIGH LEVEL LANGUAGES:
To further reduce human effort in communicating with hardware, high level languages were developed which are not bound to a specific instruction set (denoting a specific architecture). These are identical to human languages, hence easy to write, understand, debug and apply to multiple architectures. Code written in high level language is converted into low level language by Compiler - a program written in low level language. One of the most commonly used high level languages is C. But sometimes code is not pre-compiled to machine code, instead directly executed (or compiled during execution) by Interpreter. Java is one of such "write once, run anywhere" (WORA) languages which is compiled to byte-code and then interpreted by Virtual Machine - again a compiled program.
APPLICATION BINARY INTERFACE (ABI):
Since an architecture-independent program (code) can be converted to architecture-dependent code for any processor, it's the duty of compiler to take care of all the requirements of a specific architecture. That's what Application Binary Interface (ABI) defines. In simple terms, an ABI represents one or more specific architectures. Further details on Embedded ABIs require an insight into stages of Assembling and Compiling; object code, Executable and Linkable Format (ELF), static (archiving) and dynamic linking of libraries etc.
Now coming to your question:
WHAT ARE x86 AND ARM?
x86 is a family of instruction sets, mainly developed and manufactured by Intel and AMD. ARM is another family, designed by a single entity ARM Holdings and being licensed to many embedded solution manufacturers including Qualcomm, Mediatek, Samsung and Huawei. Snapdragon, Exynos and Kirin are their brand names. They are not processor manufacturers but they have licenses to include ARM processors with their own System on Chip (SoC) circuits.
WHAT IS SoC?
A System on Chip (SoC) is a small circuit that includes processors along with other components such as GPU, RAM, Flash/eMMC (equivalent of HDD or SSD), WiFi and bluetooth module, USB connectivity, UART (serial ports), JTAG (a very lower level serial communication protocol), GPS, modems (for cellular connectivity) and possibly others.
ARM ABIs:
Though the major part of Android apps is written in Java, one can program in native languages like C and C++, which needs to be compiled. Android provides its own Native Development Kit (NDK) including (libraries, header files and) a compiler that can compile code for multiple ABIs including armeabi-v7a (armhf in Linux community) and x86.
Android (Java) app itself isn't specific to an architecture. During app build process Android SDK converts Java source to bytecode (.class files) and then compiles it to Dalvik EXecutable (.dex) file which is packed with .apk files. This Dalvik bytecode is interpreted and run in a separate instance of Dalvik Virtual Machine/ART for every app by a process named Zygote. Or it can be permanently compiled to native machine code (.odex or .oat) according to the architecture of the device during installation of app (or later). But if the apk (zip) file additionally contains ELF binaries/libraries, those are architecture-specific. Developers usually include native libraries for multiple architectures in their apps.
Native applications/programs/binaries/executable/libraries built with compiler suites targeting ARM Embedded ABI v7a (armeabi-v7a) can be run on Application profile of 7th version of ARM processors (Armv7-A).
Code compiled with toolchains provided by other vendors, targeting same architecture (though with different ABI names) should also run on Android devices.
32-BIT VS. 64-BIT:
ARM processor can be 32-bit or 64-bit. It depends on SoC manufacturers what they want to build with their embedded system e.g. Snapdragon can be 32-bit or 64-bit. 32-bit ARM processors were improved for performance and new capabilities were added from version 2 to version 7. 64-bit support was introduced in ARMv8.
To find out if a device is 32-bit or 64-bit, you need to check the specifications of its SoC and then of its processor. For instance SoC in Redmi Note 4 is Qualcomm Snapdragon 625 (MSM 8953), which contains processor Cortex-A53. It's evident from technical specifications of Cortex-53 that it's based on ARMv8 architecture, which can process 2 types of Instruction Sets: aarch64 (which Android's arm64-v8a ABI uses) and aarch32 (which Android's armeabi-v7a ABI uses i.e. backward compatible with ARMv7).
So it can run binaries/libraries compiled for both of these ABIs, but not for x86 or armeabi (called armel in Linux community; which targeted architecture ARMv5/v6, and was removed in NDK r17).
source from: