Options for Releasing Native Android* Apps for Intel® Architecture (x86)

Introduction

In the Android 2.3.7 release, Intel and Google announced that they would work to enable and optimize future versions of Android to run native applications on x86 (Intel® architecture (IA))

But releasing and packaging Android NDK apps is important to developers who want to deliver better performance and user experience on each architecture. This article introduces some existing options to package Android NDK applications by analyzing some specific example applications chosen from Google Play. You can choose the most suitable option for your Android NDK application.

Options to release Android NDK apps

Table 1. Options to release Android NDK Apps

As shown in Table 1, there are generally four options for releasing Android NDK apps. They are marked with two colors. In green are Single APK and Multiple APKs, which are basic options in Google Play. Actually, those two can cover all app releases. But as you know, Android is a very open and flexible operating system. There are some special options marked with yellow: Separate APK and Tricky APK. Neither is an official Google Play option.

First, we want to explain how to analyze each option from the perspective of providing better x86 support. In the following sections, we will list “Advantages,” “Disadvantages,” “Potential Risks,” and “How to Avoid Risk” specific to x86.

Potential Risk are events that could happen if the developer adopts this option. These are based on real cases. We will also explain how to avoid the potential risk in your application.

Single APK

Table 2. Single APK Features

Type	Detail
Advantages	1. Always supports the latest version of x86. 2. Commonly found in app stores.
Disadvantages	The APK file size is large, thus taking up more memory.
Potential Risks	May lose the lib file in /lib/x86 when the app integrates a new component that doesn’t support x86.
How to Avoid Risks	Both developers and app stores need to validate app on x86 devices before going public.

Google encourages developers to develop and publish Single APK apps that support as many device configurations as possible. Definitely, the Single APK is the best and easiest option to support x86 with the latest version, indeed it is the most common option found in the app stores. But the binary will be larger.

Potential risk is that the application may lose library files when the application integrates a new component, possibly from a third party, which still does not support x86. In this case, the application will crash when launched and the system reports an error that a library file can’t be found. To avoid the risk, both developers and app stores need to validate apps on IA devices before the apps are published.

The application example is Sina Weibo, which packages all the native library files together as shown in the following screen shot.

Figure 1. Sina Weibo NDK Libs

Single APK is very suitable for lightweight NDK apps, like Sina Weibo. The total size of the four files making up the x86 library is only 235 KB, which is negligible compared to the 20 files in APK totaling 809 KB before being compressed.

Figure 2. File size of Sina Weibo x86 Libs

Multiple APKs

Table 3. Multiple APKs Features

Type	Detail
Advantages	1. Smaller APK size. 2. Always supports x86. 3. Commonly found in app stores.
Disadvantages	Just supported by Google Play
Potential Risks	A third-party app store may incorrectly push an X86-based APK to an ARM phone causing it to crash
How to Avoid Risks	The app should do CPU checking before loading native lib.

The Multiple APK option allows developers to publish different APKs for the application, each targeted to a specific device configuration, especially CPU architectures. Each APK must have the same package name but can be an independent version and a different file size.

Here is a screen shot of Chrome* for Android from Google Play. We can see that sizes and versions vary depending on the device.

Figure 3. Chrome* for Android* on Google Play

Multiple APKs have many advantages. The size of APK file downloaded to the device is smaller than the Single APK, which will save users time and reduce network traffic. Users can always get the x86 native version. And users can easily find the x86 APK since each APK shares the same application listing in Google Play. It seems to be a perfect solution. However, only Google Play supports it; most third-party app stores don’t.

The Potential Risk is that a third-party app store may incorrectly push the x86 APK to an ARM phone because x86 APK is considered wrongly by the 3rd app stores as an update version of ARM. The reason is that the version code of the x86 APK is a higher number than the ARM APK(for more detail about the version code rule, see: http://software.intel.com/en-us/articles/google-play-supports-cpu-architecture-filtering-for-multiple-apk). When the user launch this app, a crash will happen.

The best way to avoid this risk is for developers to add CPU checking to their apps before loading the native library. If the CPU architecture of target device doesn’t match the APK, a message box will pop up and notify users to download the right version.

The best solution is that for all app stores to support Multiple APKs. Then everything will work as it should.

Separate APKs

Table 4. Separate APK Features

Type	Detail
Advantages	1. Smaller APK size than Single APK. 2. Good option for developers since all app stores don’t support Multiple APKs.
Disadvantages	1. x86 version is hard to find in the app stores. 2. Users may be confused by too many app versions.
Potential Risks	ARM version may still be installed by users with x86 devices.
How to Avoid Risks	The app adds CPU checking before loading native lib and guides users to install the right version.

The most important difference between Separate APK and Multiple APKs is the package name. Here is an example app, UC Browser. We can see that there is “x86” postfix in the package name of UC Browser(X86). And the Android system considers them two different apps.

Figure 4. Package Name of UC Browser

Developers like this solution because they don’t need to maintain the x86 branch for every app version. Because the mobile internet is changing quickly, the develops have to update their mobile apps very frequently to keep up with the latest trends, but the engineering resources of the developers are limited. Separate APKs is a trade-off that allows developers to put a minimum of effort to support more architectures. The disadvantage is that the x86 version is hard to find because it is rarely downloaded as a new app.

The potential risk is that the ARM version may still be installed by users who don’t know the difference between x86 and ARM. If the app adds CPU checking before loading the native library, it will avoid this risk and guide users to download the right version.

In the long term, Separate APKs is just a temporary work-round solution and will disappear when more app stores complete Multiple APKs support.

Tricky APK

Table 5. Tricky APK Features

Type	Detail
Advantages	1. Smaller APK size than Single APK. 2. Best performance on each CPU-based device.
Disadvantages	2-step installation
Potential Risks	N/A
How to Avoid Risks	N/A

Tricky APK is a special option. The basic idea is to download the native library in two steps. You can think of this option as an update mechanism that is controlled by application itself.

MoboPlayer is an example application that uses the Tricky APK solution. More information is in the following screen shot.

Figure 3. 2-step installation of MoboPlayer NDK libs

MoboPlayer is an Android multimedia player that is based on the FFMPEG open source project. It‘s based on Single APK. At the beginning, the user just downloads an app without having to download cumbersome NDK library files. When the user first runs this app, it will check CPU type and then the app will guide the user to download the binary best optimized for the CPU architecture so that user can get maximum performance.

Summary

Several solutions are available for packaging and releasing Android NDK apps. As a developer, you should fully understand your application, especially the native code part. What is your priority? Better performance and power? APK size? Effort to support multiple CPU architectures? etc. At the same time, you should avoid the potential risk of downloading the wrong APK by adding CPU checking to your code in order to load the correct native library. Include exception handling and user guidance in case an application-APK mismatch occurs. The end goal is to deliver the best user experience on all CPU architectures.