When Google launched Android, it had a very apparent goal of portability. Starting with the underlying Linux kernel, all layers of Android are designed and implemented to be portable. Android runs on all three major processor architectures – MIPS, Intel and ARM. It also supports a variety of memory configurations, flash storage and graphics processors.

When it comes to applications, the Android team settled on Java as the preferred language for apps on Android. Pure Java apps are completely portable. They can be run on any Android platform as they have no hardware dependency.

However, in the early days of Android, application processors and graphics processors were not that powerful. The penalty of interpreting Java code led some developers to insert native code into applications to gain performance. Google also realized the need for this optimization and came up with the Android Native Development Kit – the NDK.

android ndk

There is an NDK for each architecture supported by Android – MIPS, Intel and ARM. The NDKs integrate with the Android SDK as part of the Eclipse-based toolchain for app development on Android. However, if an app uses native instructions, developers must select all of the possible NDKs. Until just last week (9/13/2012) the result was a single application binary file (an Android APK) that contained a version of the app for every architecture.

This has been called the “large Android APKs”.

The problem with large Android APKs is that, well, they can get quite big. So, installing a large APK on a user device takes far more precious flash space, not to mention bandwidth, than installing an APK that only supports the processor architecture and associated hardware of that particular device. No one likes to download large files, so most developers have actually not been building big Android APKs. Instead they have typically either selected a single architecture for an app (which is non-portable and therefore limits potential app sales), or they have made multiple APKs that support all the target architectures available – so called “thin APKs”.

While that sounds like an obvious solution, it is a challenge for developers: each thin APK required a unique name in the Google Play app store. The result was a logistical nightmare for developers. No one likes to maintain multiple copies of essentially the same app under different names.

It could be even more confusing for the end user, who might have to choose between different listings for a single app.

Google has finally solved all these problems by leveraging the manifest facility.

Each device has a manifest that it makes available to an app store when a user visits the store. The manifest lists what hardware the device supports, and which version of Android is running on the device. Similarly, each app also has a manifest that indicates if it has any special requirements in terms of processor architecture, graphics support, etc. When a user visits an app store, (such as Google Play) the store uses these two manifests to select which apps the user can see and download.

Google decided to further leverage manifests and make a major change to the Play store’s infrastructure: a single name/description entry can now be automatically associated with multiple thin APKs. If the user buys/downloads an app, the store will select the correct thin APK for that device using the relevant manifests. Things just became a lot simpler for developers and for their customers.

In addition, Google has provided app developers with some clear documentation of what has changed and how to make use of it:

http://developer.android.com/guide/google/play/publishing/multiple-apks.html

This fits perfectly with the overall portability goal of Android. Now developers building native apps can automatically support all of the major architectures and deploy their apps without needing to construct a clever naming system. End users will be able to access native apps transparently – no matter what processor architecture their devices are based around.

Furthermore, if a user changes his/her device and moves to a different processor architecture, when his/her apps are restored, the Play store will automatically selected the right think APK for the new device. Pure magic.

Developers can now easily build and, more importantly, deploy native apps suitable for use on any device supporting Android. Apps become available across all architectures. End users see simplified listing and can select their hardware based on price/performance/features and not have to worry about app availability. Everybody wins.

So, big APKs are out, long live small Android APKs!

About the author: MIPS Developer Team

Profile photo of mipsdeveloperteam