//tools/grit/pak_util.py can list strings in a pak file.

"aapt dump strings" can list strings in an apk's resources.arsc file.

The task would be to dump both of these and cross reference to see how much duplication there is (Just looking at en-US.pak should be fine)

Created a script to check the duplication between the .arsc and .pak files.

There are 282 shared strings between in.pak and in.arsc.
The total size of the strings is 5038 chars.

The in.pak file was created by using //tools/grit/pak_util.py print /path/to/pakfile > in.pak
The in.arsc file was created by using aapt dump strings ChromePublic.apk > in.arsc
The script was run using: python compare.py in.pak in.arsc

Deleted: compare.py 1.1 KB

compare.py 1.1 KB View Download

Great! Thanks for looking into this!

Going by our logic here:
https://cs.chromium.org/chromium/src/build/android/resource_sizes.py?rcl=ea39f3af5a95daec14256f088c17b6a3acae846d&l=280

This would be:
(5038 + (7 * 282)) * 1.5 * 54 = 567,972 of uncompressed bytes within resources.arsc

A few complications in terms of actually de-duping these though:
 * Need to add a PakFile.getString() (no JNI required, the file format is easy)
 * Layouts (or other xml) that reference strings cannot be implicitly switched to Pak.
   * Code goes through TypedArray.getText, which goes into native code.
 * Need to either:
   a) Change usages of getResources().getString() -> PakFile.getString()
   b) Implement a custom Resources class that maps getString(arscId) -> Pakfile.getString(pakId)
 * Need to not break unused resource filtering. 

 Issue 710081  has been merged into this issue.

Next step in this adventure is to ensure these duplicates are even used at all on the java side. Blocking this bug on 636448

With locales loaded via dynamic modules, the multiplier here goes away, and the effort wouldn't be worth it:

(5038 + (7 * 282)) * 1.5 * 2 ~= 20kb.

We would likely add >= 20kb of code to support sharing.

Yep, I agree :-/