Mobile phone CPU structure, ARM

Problem description

Today testers test the integration version in addition to a bug: about the Huawei Mate 8 Mobile Android 6.0 system running just the version of the test, there is a flash bug, and Xiaomi 4 mobile phone Android 6.0 system did not appear any bug, run well. Later view the code of my relevant module, found that I integrated version of the relevant module code and branch version of the code of the relevant module is exactly the same, that is to say I merge the branch code into the skeleton code is no problem, so to see the skeleton code problems.

After a look at the submission log, found that a colleague and I merged the code, submitted a friend to push the so file record, originally he joined a arm64-v8a folder, there are friends of the push arm64-v8a so library files. The other so library text does not have a corresponding version of arm64-v8a.

Through Baidu to know that there is an explanation about ARM64-V8A:

ARM64-V8A is backwards compatible, but only if there is no arm64-v8a folder inside your project, if you have two folders Armeabi and arm64-v8a, two folders, Armeabi with a.so and b.so inside, ARM64-V8A inside only a.so, then arm64-v8a cell phone in use to B when found there arm64-v8a folder, found there is no b.so, on the error, so this time delete arm64-v8a folder, this time the phone found no fit arm64-v8a, will go directly to find Armeabi so library, so either you do not add arm64-v8a, or armeabi inside some so library, arm64-v8a inside must have

Green Jim
Links: http://www.zhihu.com/question/36893314/answer/78467097
Source: Know
Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source.

found that the original Huawei Mate 8 mobile phone is 64-bit operating system, and Xiaomi 4 mobile phone is 32-bit operating system, so Xiaomi 4 mobile phone running app is not a bug, and Huawei Mate 8 mobile app has a flash back bug.

Workaround 1, before the resolution:

As can be seen, the first project has arm64-v8a, and there is no x86 directory, the second project does not have arm64-v8a, and there is a x86 directory. The first project is imported into the second project as a project reference.

2, after the settlement:

As can be seen, in the first project and the second project does not have the Libs directory, are armeabi-v7a, Armeabi, x86 three directories, consistent. The first project is imported into the second project as a project reference.

3. Solution:

The solution is: from the AU official to download x86 related so files, placed in the x86 directory, the ARM64-V8A directory deleted. All about the so file should be consistent, that is: if you want to add a armeabi-v8a directory, the following armeabi-v8a related to the third party so file, then you need to have other so files to armeabi-v8a version, otherwise it will be an error.

The following article is reproduced in asce1885 (book author): What you need to know about Android. so files
(Original link: http://www.jianshu.com/p/cb05698a1968)
Copyright belongs to the author, please contact the author to obtain authorization, and Mark "book author".

The early Android system almost only supported the ARMV5 CPU architecture, do you know how many kinds it supports now? 7 Kinds!

The Android system currently supports the following seven different CPU architectures: Armv5,armv7 (since 2010), x86 (from 2011 onwards), MIPS (from 2012 onwards), Armv8,mips64 and x86_64 (from 2014), Each one is associated with a corresponding ABI.

The Application Binary interface (application binary Interface) defines how binary files (especially. so files) run on the appropriate system platform, from the instruction set used, to the memory alignment to the available system function libraries. On an Android system, each CPU architecture corresponds to a abi:armeabi,armeabi-v7a,x86,mips,arm64-v8a,mips64,x86_64.

Why you need to focus on. so files

If the NDK is used in the project, it will generate a. so file, so obviously you are already watching it. If you're just coding in the Java language, you might be thinking that you don't need to focus on. So files, because Java is cross-platform. But in fact, even if you only use the Java language in your project, in many cases you may not be aware that the library or engine library that you are relying on in your project has embedded the. So file and relies on different ABI.

For example, in a project that uses the Renderscript support library, Opencv,unity,android-gif-drawable,sqlcipher, and so on, you have already included the. So file in the generated APK file and you need to follow the. so file.

The ABI supported by Android apps depends on the. So file in the Lib/abi directory in the APK, where the ABI may be one of the seven Abi mentioned above.

Native Libs Monitor This app can help us understand which. so files are used by the APK installed on the phone, and which libraries or frameworks the. so file originates from.

Of course, we can also decompile the app ourselves to get this information, but it's a bit more cumbersome.

Many devices support more than one ABI. For example, ARM64 and x86 devices can also run binary packages of armeabi-v7a and Armeabi at the same time. However, it is best to provide a platform-specific binary package for a particular platform, in which case there is less of a simulation layer (for example, a virtual layer on the x86 device simulating arm) for better performance (thanks to recent schema updates such as hardware FPU, more registers, better vectorization, etc.).

We can get the list of ABI supported by preference-based devices via Build.supported_abis. But you should not read it from your application because Android Package Manager will automatically select the. so file in the APK package for the corresponding system ABI when it is installed, if there is a. so file in the corresponding Lib/abi directory.

Where the app might go wrong

There is an important law that is simple but not well known when working with. so files.

You should provide as much as possible the. so files optimized for each ABI, but either all supported or not supported: you shouldn't mix it up. You should provide a corresponding. So file for each ABI directory.

When an app is installed on a device, only the. so files that the device supports for the CPU architecture are installed. On the x86 device, libs/ If the. So file is present in the x86 directory, it will be installed, if it does not exist, the. So file in the armeabi-v7a is selected, and if it does not exist, select the. so file in the Armeabi directory (because the x86 device also supports armeabi-v7a and Armeabi).

Other places could be wrong.

When you introduce a. So file, it not only affects the CPU architecture. I can see a number of common errors from other developers, most of which are "Unsatisfiedlinkerror", "dlopen:failed" and other types of crash or low performance:

. So files compiled with the ANDROID-21 platform version run on ANDROID-15 devices

When using the NDK, you may prefer to use the latest compilation platform, but in fact this is wrong, because the NDK platform is not back-compatible, but forward-compatible. It is recommended to use the minsdkversion of the app to compile the platform.

This also means that when you introduce a precompiled. So file, you need to check the version of the platform that it was compiled with.

Mixing. So files that are compiled with different C + + runtimes

. So files can depend on different C + + runtimes, statically compiled or dynamically loaded. Mixing with different versions of C + + runtime can lead to a lot of strange crash that should be avoided. As a rule of thumb, when there is only one. So file, it is no problem to compile the C + + runtime statically, otherwise when there are multiple. so files, all. So files should be dynamically linked to the same C + + runtime.

This means that when a new precompiled. So file is introduced, and there are other. So files in the project, we need to first confirm that the C + + runtime used by the newly introduced. So file is consistent with the. So file that already exists.

No corresponding. So files are provided for each supported CPU architecture

This has been said in the previous article, but you should really pay special attention to it, because it could happen without realizing it at all.

For example: Your app supports armeabi-v7a and x86 architectures, and then uses Android studio to add a library dependency, which contains. so files and supports more CPU architectures, such as the New Android-gif-drawable library:

compile ‘pl.droidsonroids.gif:android-gif-drawable:1.1.+’

• 1

• 1

When we publish our app, we'll find that it crash on some devices, such as the Galaxy S6, and eventually you'll find that only the. so files in the 64-bit directory are installed into the phone.

Solution: Recompile our. So file to support missing Abis, or set

ndk.abiFilters

• 1

• 1

Displays the specified supported Abis.

The last point: if you are an SDK provider, but the provided libraries do not support all Abis, then you will screw up your users because they can support abis that will only be less than what you provide.

Put the. So file in the wrong place

We tend to be confused about where the. So file should be placed or generated, here's a summary:

• The Android Studio project is placed in the Jnilibs/abi directory (and can of course be specified by setting the Jnilibs.srcdir property in the Build.gradle file)
• The Eclipse project is placed in the Libs/abi directory (this is also the directory where the Ndk-build command generates. So files by default)
• The AAR package is located in the Jni/abi directory (. So files are automatically included in the apk that references the AAR compression pack)
• In the Lib/abi directory in the final APK file
• After installing via Packagemanager, the. So file is located in the app's Nativelibrarypath directory on systems smaller than Android 5.0, and on systems greater than or equal to Android 5.0. The so file is located in the app's Nativelibraryrootdir/cpu_arch directory.

only. So files with Armeabi schemas are provided and other abis are ignored

All X86/X86_64/ARMEABI-V7A/ARM64-V8A devices support the. So file of the Armeabi architecture, so it seems that removing other abis. So files is a good technique to reduce the size of the APK. But not really: this affects not only the performance and compatibility of the library.

The x86 device works well with the arm type library, but does not guarantee that 100% does not occur crash, especially for older devices. 64-bit devices (arm64-v8a, x86_64, MIPS64) can run 32-bit libraries, but run in 32-bit mode and run 32-bit versions of ART and Android components on 64-bit platforms, losing performance optimized for 64-bit (Art,webview, Media, and so on).

To reduce the size of the APK package is a false excuse, because you can also choose to upload the specified ABI version of the APK in the app market, generate different ABI version of the APK can be configured in Build.gradle as follows:

Android {... splits {abi {enable true reset () include' x86 ',' X86_64 ',' armeabi-v7a ',' arm64-v8a '//select ABIs to build APKsFor universalapk true//generate a additional APK that contains all the ABIs}}//MapFor the version code project.ext.versionCodes = [ ' Armeabi ': 1,  ' armeabi-v7a ': 2,  ' arm64-v8a ': 3,  ' MIPS ': 5,  ' mips64 ': 6,  ' x86 ': 8,  ' x86_64 ': 9] Android.applicationVariants.all {variant--//Assign different version code for each output Variant.outputs.each {output, output.versioncodeoverride = Project.ext.versionCodes.get (Output.getfilter (Com.android.build.OutputFile.ABI), 0) * Span class= "Hljs-number" >1000000 + Android.defaultConfig.versionCode}}       

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21st
• 22

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21st
• 22

More references

• What you should be aware of in the Android so library
  (http://www.voidcn.com/blog/u013278099/article/p-4944290.html)

• Android Development, a known so file knowledge Daquan
  http://alphayang.community/2015/11/27/so-files-guide/

Mobile phone CPU structure, ARM