Turns out that file paths account for a non-trivial amount of space, because they exist:

* In each zip entry
* In the zip central directory
* In resources.arsc
* In META-INF/foo.MF (compressed at 68%)
* In META-INF/foo.SF (compressed at 68%)

$ unzip -l out/Release/MonochromePublic.apk | grep res/ | wc -l
2437
$ unzip -l out/Release/MonochromePublic.apk | grep res/ | cut -c31- | wc -c
115065
Subtracting off newlines: 115065-2437=112628

Average path length = 112628 / 2437 = 46.2


We could store each path using just two characters (64*64=4096, which is > 2437).
Old size: 3.6 * 112628 = 405461
New size: 3.6 * 2437 * 2 = 17546
Savings: 405461 - 17546 = 387915

Things that might trip us up here:
1) Is it okay to remove the res/foo/ path prefix? I'd hope it's fine since resources.arsc encodes the config information.
2) Is it okay to drop file extensions? E.g. .xml, .png, .webp. Decoders may rely on this.
3. We don't want to break file-by-file patches, so we'd need to be consistent between releases when renaming paths. We have the same concern for renaming with proguard, so we could likely solve this in the same way (record the mapping, or use file name hashes).


How to go about making this change:
Option 1: Post-process
 * E.g. Right before signing, rewrite resources.arsc and rename files.

Option 2: Add support to aapt2
 * aapt2 is the tool that generates resources.arsc, so we could add a flag to it minimize file names and output a mapping.

Either way, we should store mappings along side apk, and ensure we archive them for builds.