When developing an Android app, any data file, image or XML file (that is, any Resource or Asset) you use is bundled into your application package (APK) for distribution. The Android Asset Packaging Tool, or aapt, is responsible for creating this bundle, which you can think of as a ZIP file with a particular layout that the Android OS can understand. When your application is installed, whether in development mode or by an end user, this APK file is simply dropped into a special location on the device’s (or emulator’s) filesystem.
As part of preparing your APK, aapt selectively compresses various assets to save space on the device. The way aapt determines which assets need compression is by their file extension. The following code, taken from Package.cpp in the aapt source code, sheds some light on which types of files are not compressed by default:
/* these formats are already compressed, or don't compress well */
static const char* kNoCompressExt[] = {
".jpg", ".jpeg", ".png", ".gif",
".wav", ".mp2", ".mp3", ".ogg", ".aac",
".mpg", ".mpeg", ".mid", ".midi", ".smf", ".jet",
".rtttl", ".imy", ".xmf", ".mp4", ".m4a",
".m4v", ".3gp", ".3gpp", ".3g2", ".3gpp2",
".amr", ".awb", ".wma", ".wmv"
};
The only way (that I’ve discovered, as of this writing) to control this behavior is by using the -0 (zero) flag to aapt on the command line. This flag, passed without any accompanying argument, will tell aapt to disable compression for all types of assets. Typically you will not want to use this exact option, because for most assets, compression is a desirable thing. Sometimes, however, you will have a specific type of asset (say, a database), that you do not want to apply compression to. In this case, you have two options.
First, you can give your asset file an extension in the list above. While this does not necessarily make sense, it can be an easy workaround if you don’t want to deal with aapt on the command line. The other option is to pass a specific extension to the -0 flag, such as -0 db, to disable compression for assets with that extension. You can pass the -0 flag multiple times, and each time with a separate extension, if you need more than one type to be uncompressed.
Currently, there is no way to pass these extra flags to aapt when using the ADT within Eclipse, so if you don’t want to sacrifice the ease of use of the GUI tools, you will have to go with the first option, and rename your file’s extension.
So, Why Disable Compression Anyway?
For most types of assets, you shouldn’t need to be concerned with how they are packaged. Given the list of extensions above, Android will do the right thing for a large subset of the files you’ll use. If you have a type of asset that is already compressed by nature of the file type, but doesn’t have one of the sanctioned extensions, you can typically ignore that inconsistency and just allow aapt to try to compress it. It will not be very much, if at all, smaller in the final APK, but the performance hit should be relatively minimal unless you just have tons of these files.
This begs the question, why even bother disabling compression? The not-so-obvious answer is that any compressed asset file with an uncompressed size of over 1 MB cannot be read from the APK. This could come into play if your asset needed to be copied out of the APK and into the app’s writable files area, for example to provide a pre-populated database in your app. When you try to use the various AssetManager or Resources classes’ methods to get an InputStream to the file, it will throw an exception and display a LogCat message like this:
DEBUG/asset(725): Data exceeds UNCOMPRESS_DATA_MAX (1662976 vs 1048576)
The only way around this type of issue is to disable compression for assets that exceed the 1 MB limit. If your file format supports it, you can choose to split the asset into several smaller files that have an uncompressed size of less than 1 MB each, but this can be a real annoyance.
Hopefully the knowledge in this post can help you avoid the headaches I went through to learn it!