As much as I hate the APK file format, this is not a valid reason why, as Google covered this. When you build your APK, you are more than welcome to simply not compress certain files, as the .zip file format has an algorithm that is just "store". In fact, the SDK does this by default for certain kinds of commonly-mapped files that don't benefit much from compression anyway, such as .mp3. I am not certain if aapt lets you specify other files easily, but you can always just add your own stored content using the zip tool itself.
Then, the normal build process has you run "zipalign" on the resulting file, which will guarantee that uncompressed files fall on boundaries that would make them efficient to memory map directly out of the APK. Finally, the AssetManager API provides an openFd() method that will open a file (which must be uncompressed, or you will get an IOException), return a file descriptor for that file, and tell you the offset into that file where the data for the file you wanted starts (an API sufficient to describe a range of an APK).
You are right, this is the best workaround possible. This is still a workaround since it need to memory map the whole APK file.
In our case this is not really acceptable since we develop a SDK that is embedded by developers in their app and this would put constraints on their app if they want to embed an index.
Btw I think an evolution of the APK format could be to have 2 different parts:
- a part that contains compressed data and stay on disk to launch the app
- a part that is only used only for installation: extract uncompressed files and store them on file system.
I do not understand why this would possibly be a concern.
You do realize that there is no cost to memory mapping a very large file, right? You still are going to end up with only a single VMA ("virtual memory area", one of the more insidious costs of memory maps) in your memory map, and only pages you use will get paged in; if you wanted to memory map a 1GB large file, the only pain would be the loss of address space, and you have 2-3GB of that available.
Additionally, you aren't even correct that you have to memory map the entire file: as you have a file descriptor for the file and know the offset you want into the file, you can memory map just the part of the file you need. Both the C-level mmap API and the Java-level FileChannel.map API allow you to provide a specific offset and length for the region you want to map from the file.
Yes this is true than jar files have the same issue but in the case of Java applications you can have an installer and package others files with your application.
In the case of Android, you are forced to package all application files in an APK file.
Then, the normal build process has you run "zipalign" on the resulting file, which will guarantee that uncompressed files fall on boundaries that would make them efficient to memory map directly out of the APK. Finally, the AssetManager API provides an openFd() method that will open a file (which must be uncompressed, or you will get an IOException), return a file descriptor for that file, and tell you the offset into that file where the data for the file you wanted starts (an API sufficient to describe a range of an APK).