When Google launched Android, portability was a primary goal, so, starting with the underlying Linux kernel, all layers of Android are designed and implemented to be portable. The Android team settled on Java as the preferred language for Android applications because Java apps can be run on any Android platform, since they have no hardware dependencies.
However, in the early days of Android, application processors and graphics processors were not that powerful. To avoid the penalty of interpreting Java code, some developers inserted 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.
There is an NDK for each architecture supported by Android – MIPS, Intel, and ARM. The NDKs integrate with the Android software development kit (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 “fat APK”.
The problem with fat APKs is that…well, they are fat! So, installing a fat 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 fat 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 – called “thin APKs”.
While that sounds like an obvious solution, thin APKs are a challenge for developers: each thin APK requires 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, making things a lot simpler for developers and for their customers.
In addition, Google has provided app developers with clear documentation of what has changed and how to make use of it, available here .
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 upon.
Furthermore, if a user changes his/her device and moves to a different processor architecture, then when his/her apps are restored the Play store will automatically select the right thin 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 listings and can select their hardware based on price/performance/features and not have to worry about app availability. Everybody wins.
So, FAT APKS are out. Long live THIN APKs!
Robert Bismuth joined MIPS Technologies in 2011 as Vice President of Business Development. Prior to this, he served as an executive at technology companies including Digital Equipment Corporation (DEC), ConneXt, Transmeta Corporation, and Unidym Corp. Early in his 30-plus year career, Mr. Bismuth founded his own technology company in the United Kingdom. He has also served on the boards and advisory boards for a diverse set of technology companies.