

Why Android APK Format is a Mistake - jlemoine
http://blog.algolia.com/why-android-apk-format-is-a-terrible-mistake

======
saurik
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).

~~~
jlemoine
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.

~~~
saurik
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.

------
blibble
I'd argue that it's just a standard engineering trade-off rather than a
mistake.

jar files have exactly the same issues.

~~~
jlemoine
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.

