WebView doesn't have too many its own resources, basically, Chrome includes almost all WebView resources, If we have separated pak file, we need specific code to handle this,   we don't want content and below layer or components are aware that it is running as WebView or Chrome.

We might go other way to resolve redundant languages issue. 

re #1 - what do you mean by the other way around?

Also - an estimate of savings:
SystemWebviewGoogle sum of locale paks (stored): 536,673
Chrome.apk sum of locale paks (defl): 1,663,179
Monochrome sum of locale paks (stored): 6,989,335

New approach = Chrome.apk + SystemWebviewGoogle.apk = 2,199,852
Delta = Monochrome - New approach = -4,789,483

Two follow-on ideas:
1. If we did the trick where we use an IPC to Monochrome.apk and ask it to extract the locale pak to its data directory (and make it a+r), then we could save another 500kb at the expense of start-up time when the .apk is updated

2. If instead we keep them separate, but compress & unzip to memory, the webview locale paks would consume 203,967 (300kb savings) and require 10-15kb of RAM (that's how big each one is)

Re #5
I probably don't fully understand your ideas, here is my two cents.

1) the resources used by WebView can't be extract to data directory. In WebView context, the data directory is app's data directory.

2) I think memory usage has priority than storage, beside the performance impact, that memory can't be shared between processes, right? but the mmap is shared, so memory usage will be increase a lot.


As to apk size, do you want to pursue 'download as demand', I don't know how feasible it is, but it is pretty interesting idea for me. 

1) WebView can't extract, but it can send an intent to chrome and ask it to extract to chrome's directory. It can then chmod a+r and webview can then read it.

2) Hadn't thought about multi-process affect. Probably could be solved with ashmem though?

I don't want to pursue downloading on demand. Some thoughts here:
https://bugs.chromium.org/p/chromium/issues/detail?id=369218#c50

1) It is probably a little weird to let webview (actually apps) to tell chrome to do something, +torne, he probably has some ideas.

1) Is there security issue here? it pretty much every app can send intent to chrome for extracting resource, chrome will be startup unnecessarily. 

I don't see how it could be a security issue. You can already read any other app's .apk file.

Any other app can already intent to chrome to have it open.

I'm pretty reluctant to have webview depend on chrome actually doing anything in order to function, even though it's possible as you describe.

The memory usage issue Michael raises isn't just about multiprocess - remember that there can simply be more than one app using webview at once, and so even in single process, these would all be duplicating the same dirty memory. There's no way for separate apps to share these pages, even if we implement sharing between browser and renderer in multiprocess.

Startup time and memory usage is already extremely critical for WebView. Extracting locale paks at startup, even if it was 100% reliable, is going to add another case where sometimes WebView's startup is significantly slower. I realise this is only going to happen once per update/locale/device, but Android (and developers) both notice these things and there's already existing cases where the startup time is unacceptably high on slower devices. There's also a momentary memory usage spike there, because you'll have to create the Chrome process - this is going to be fighting the app that's trying to start up and use webview for memory (and IO bandwidth), and on a very constrained device it's not out of the question that you might occasionally OOM and kill one of the involved processes here :(

Splitting the locale paks up so that there's an uncompressed pak containing the strings webview cares about, and a compressed one containing the strings that only chrome uses, seems like a more viable option, though harder to implement I expect.

Issue 698262 has been merged into this issue.

very brief doc
https://docs.google.com/a/chromium.org/document/d/1xCJHLrjILMN8Nv4ec-p7lw_hZHMoUllbqZf7lomDCXs/edit?usp=sharing

The final design for this doesn't have WebView depend on Chrome to do anything - it's to split the locale paks up, which is safe, so my concerns are addressed :)

Note: It might be worth a follow-up iteration to remove the duplication, and have IDs that are missing from the chrome paks fall back to the webview paks.

Just did a quick check to see how many resources are shared:
$ wc -l < libwebviewchromium.so.whitelist
1188
$ cat libwebviewchromium.so.whitelist libchrome.so.whitelist > both.whitelist
$ wc -l < both.whitelist
3679
$ sort --unique < both.whitelist | wc -l
2499

So, 3679-2499=1180 IDs are duplicated... which is all but 8 :P

But that's all resources, including things in the main, non-locale-specific pak, no? The WebView locale paks are tiny, I think we include very few translated strings.

Hmm, yeah, you're right.

Did the same trick again, this time by just extracting en-US.pak from SystemWebviewGoogle.apk (using a tweaked //chrome/browser/resources/unpack_pak.py).

Of the 231 IDs in webview's en-US.pak, 225 of them exist in Chrome's whitelist.

Webview's locale paks are 534451 bytes.
If you compress them, they are 215380 bytes.
So I'd guess the extra savings of removing the duplicates to be ~200kb (since we'd effectively be deleting the compressed duplicates).

OK, well, up to you if you want to figure out a way to get those 200KB, since it'd just be a change to Chrome's handling of the paks :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b19aa78ac188365efe6b54c3889d67e9225b10d2

commit b19aa78ac188365efe6b54c3889d67e9225b10d2
Author: zpeng <zpeng@chromium.org>
Date: Thu May 18 14:38:22 2017

Separate WebView's locale paks from Chrome's locale paks

In order to reduce APK size, this CL separates WebView's locale paks
from Chrome's locale paks, and compresses locale paks for all flavors
of Chrome.

Previously, Chrome and Chrome modern have their locale paks compressed,
while their contemporary WebView is shipped as a standalone APK and has
its own locale paks stored uncompressed. For Monochrome, WebView and
Chrome share uncompressed locale paks. As a result, Monochrome locale
paks take up lots of disk space unnecessarily.

This CL changes WebView locale pak location for all WebViews, and
compresses Chrome's locale paks in Monochrome. As a result, Monochrome
now contains uncompressed WebView locale paks and compressed Chrome
locale paks. Other resources are not affected. This greatly reduces
locale paks' footprints on disk. Monochrome.apk shrinks by 2.6MB.

A side effect for this CL is that Monochrome no longer supports several
locales that have been unsupported by Chrome and Chrome modern but
supported by WebViews.

See  crbug.com/687797  for more details.

BUG= 687797 

Review-Url: https://codereview.chromium.org/2890813002
Cr-Commit-Position: refs/heads/master@{#472801}

[modify] https://crrev.com/b19aa78ac188365efe6b54c3889d67e9225b10d2/android_webview/BUILD.gn
[modify] https://crrev.com/b19aa78ac188365efe6b54c3889d67e9225b10d2/chrome/android/BUILD.gn
[modify] https://crrev.com/b19aa78ac188365efe6b54c3889d67e9225b10d2/chrome/browser/chrome_browser_main_android.cc
[modify] https://crrev.com/b19aa78ac188365efe6b54c3889d67e9225b10d2/chrome/chrome_paks.gni
[modify] https://crrev.com/b19aa78ac188365efe6b54c3889d67e9225b10d2/ui/android/java/src/org/chromium/ui/base/ResourceBundle.java

Created  crbug.com/724110  to track removing duplicates

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1df3575f49c762037f3c3af6451a4b9e0e79ac88

commit 1df3575f49c762037f3c3af6451a4b9e0e79ac88
Author: estevenson <estevenson@chromium.org>
Date: Fri May 19 00:18:07 2017

Revert of Separate WebView's locale paks from Chrome's locale paks (patchset #3 id:60001 of https://codereview.chromium.org/2890813002/ )

Reason for revert:
Broke downstream bot: https://bugs.chromium.org/p/chromium/issues/detail?id=724277

Original issue's description:
> Separate WebView's locale paks from Chrome's locale paks
>
> In order to reduce APK size, this CL separates WebView's locale paks
> from Chrome's locale paks, and compresses locale paks for all flavors
> of Chrome.
>
> Previously, Chrome and Chrome modern have their locale paks compressed,
> while their contemporary WebView is shipped as a standalone APK and has
> its own locale paks stored uncompressed. For Monochrome, WebView and
> Chrome share uncompressed locale paks. As a result, Monochrome locale
> paks take up lots of disk space unnecessarily.
>
> This CL changes WebView locale pak location for all WebViews, and
> compresses Chrome's locale paks in Monochrome. As a result, Monochrome
> now contains uncompressed WebView locale paks and compressed Chrome
> locale paks. Other resources are not affected. This greatly reduces
> locale paks' footprints on disk. Monochrome.apk shrinks by 2.6MB.
>
> A side effect for this CL is that Monochrome no longer supports several
> locales that have been unsupported by Chrome and Chrome modern but
> supported by WebViews.
>
> See  crbug.com/687797  for more details.
>
> BUG= 687797 
>
> Review-Url: https://codereview.chromium.org/2890813002
> Cr-Commit-Position: refs/heads/master@{#472801}
> Committed: https://chromium.googlesource.com/chromium/src/+/b19aa78ac188365efe6b54c3889d67e9225b10d2

TBR=agrieve@chromium.org,michaelbai@chromium.org,torne@chromium.org,thakis@chromium.org,zpeng@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 687797 

Review-Url: https://codereview.chromium.org/2894763002
Cr-Commit-Position: refs/heads/master@{#472988}

[modify] https://crrev.com/1df3575f49c762037f3c3af6451a4b9e0e79ac88/android_webview/BUILD.gn
[modify] https://crrev.com/1df3575f49c762037f3c3af6451a4b9e0e79ac88/chrome/android/BUILD.gn
[modify] https://crrev.com/1df3575f49c762037f3c3af6451a4b9e0e79ac88/chrome/browser/chrome_browser_main_android.cc
[modify] https://crrev.com/1df3575f49c762037f3c3af6451a4b9e0e79ac88/chrome/chrome_paks.gni
[modify] https://crrev.com/1df3575f49c762037f3c3af6451a4b9e0e79ac88/ui/android/java/src/org/chromium/ui/base/ResourceBundle.java

Based on the design, the stored locales pak files should be same as those in standalone webview apk which is built without the patch, and the compressed locales pak file should be same as those in Monochrome.apk which is built without patch also.

You could verify your change by this way.

discussed with zpeng@, and the compressed locales pak file should be same as those in standalone chrome.apk which is built without patch.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/14032b2d2be329df3b8115b821a30518941a6226

commit 14032b2d2be329df3b8115b821a30518941a6226
Author: zpeng <zpeng@chromium.org>
Date: Tue May 23 20:12:45 2017

Reland of Separate WebView's locale paks from Chrome's locale paks (patchset #1 id:1 of https://codereview.chromium.org/2894763002/ )

Reason for reland:
Bot failure no longer reproducible locally

TBR=agrieve@chromium.org,michaelbai@chromium.org,torne@chromium.org,thakis@chromium.org,estevenson@chromium.org
BUG= 687797 

Review-Url: https://codereview.chromium.org/2896313002
Cr-Commit-Position: refs/heads/master@{#474023}

[modify] https://crrev.com/14032b2d2be329df3b8115b821a30518941a6226/android_webview/BUILD.gn
[modify] https://crrev.com/14032b2d2be329df3b8115b821a30518941a6226/chrome/android/BUILD.gn
[modify] https://crrev.com/14032b2d2be329df3b8115b821a30518941a6226/chrome/browser/chrome_browser_main_android.cc
[modify] https://crrev.com/14032b2d2be329df3b8115b821a30518941a6226/chrome/chrome_paks.gni
[modify] https://crrev.com/14032b2d2be329df3b8115b821a30518941a6226/ui/android/java/src/org/chromium/ui/base/ResourceBundle.java

This appears not to have had the desired effect: WebView still extracts the Chrome compressed locale paks on startup, wasting disk space and startup time, and blocking startup with a synchronous task. See  issue 752510 .