It should be noted that generally using multiple APKs to target different device configurations is discouraged.
The best place to learn about this is by reading the Android documentation about Multiple APK support. It is possible to upload separate APKs to the play store for each ABI you are targeting. The reason for this is that all devices running the armeabi-v7a are also able to execute the armeabi native code. Notice in the table shown in Figure 5 that uploading an APK with armeabi native code will target 12 more devices than uploading an APK containing armeabi-v7a native code. Here is an example of the results:įigure 5: Play store reported supported devices When uploading an app to the Play Store feedback is shown with regards to the number of devices that are able to run your APK. There is a small percentage of x86 devices and virtually no MIPS devices. ARM architectures dominate the Android device marketplace. While I have not been able to source official figures for sales figures of devices running each architecture, the breakdown is pretty clear through casual observation. Play Store Device support for different ABIs You will increase the size of your APK (if building one APK with all native libraries).
You may see a small increase in performance for 64 bit devices.
You will not support any more devices than if you only include 32 bit libraries.You will still need to include 32 bit native libraries.In summary, if you include 64 bit native libraries in you app: Intel® have done some tests on Android performance using 64 bit compared to 32 bit and found performance is generally increased by 5-10%. If you provide native libraries specifically for 64 bit devices you should see a small performance increase with these new devices. This applies to ARM as well as Intel and MIPS devices.ĭuring 2015 sales of 64 bit Android devices could overtake those of 32 bit devices in some markets. All 64 bit ABIs are backward compatible to support native libraries built for the equivalent 32 bit ABI. Note: It is not mandatory to build 64 bit libraries to support 64 bit Android devices. Up until the start of 2015 this was an easy decision as 64 bit devices were only just hitting the market. When including native libraries you have to make a decision if you are going to ship with native libraries specifically targeting the 64 bit ABIs.
On less intensive use cases there will be little, if any, performance benefit.įigure 4: APK size effect of including SQLCipher native libraryįor more information take a look at how to set your adle file to build APKs that target different ABIs. During some basic testing to compare some similar algorithms in native code compared to Java, I found the result ranged from double to a 20 times performance increase, however it should be noted these algorithms were heavy image manipulation processing. Ease of reuse: The SQLCipher library was already developed in C/C++, using a native library makes is easier than rewriting and maintaining the library in different languages for different platformsīuilding a shared native library can provide significant performance increases compared with implementing the same algorithm in Java.Performance benefits: SQLCipher has to decrypt/encrypt data, which requires very intensive processing.SQLCipher is a great example of where using native libraries in Android is a necessity, here’s why: In this article I will use the SQLCipher project as an example use case for native libraries. Figure 1 shows a summary of the pros and cons of using native libraries:įigure 2: Android ABI support Shared native library example Including native libraries in your app results in you losing the write once, run anywhere benefit. Most apps won’t benefit from native libraries and most apps should be developed exclusively using Java, which is executed in a virtual machine on the device using the Java ‘Write once, run anywhere’ philosophy. Head to the Android NDK site for the tools and information you need to build native libraries for Android.
Note: The process of building a native library is not covered in this article.
The main drivers for Android developers to include native libraries are: Even if you haven’t directly built native code libraries, you may have included pre-built native libraries they can be identified by the. Libraries written in C++ and C have long been supported in Android through the Native Development Kit (NDK).