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

commit 8f59a30117fb0a3ac62aa653a5c3d79249939bfe
Author: agrieve <agrieve@chromium.org>
Date: Wed Sep 28 20:00:08 2016

Move Monochrome locale_pak_resources target upstream

This includes a "monochrome_public_apk_tmpl" so that the
downstream reference to locale_pak_resources can be removed.

BUG=641032, 650927 

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

[modify] https://crrev.com/8f59a30117fb0a3ac62aa653a5c3d79249939bfe/chrome/android/BUILD.gn
[modify] https://crrev.com/8f59a30117fb0a3ac62aa653a5c3d79249939bfe/chrome/android/chrome_public_apk_tmpl.gni
[modify] https://crrev.com/8f59a30117fb0a3ac62aa653a5c3d79249939bfe/chrome/android/monochrome_repack_locales.gni
[modify] https://crrev.com/8f59a30117fb0a3ac62aa653a5c3d79249939bfe/chrome/chrome_paks.gni

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

commit be18d7c8226d8949d9b840a99b365e032697becf
Author: agrieve <agrieve@chromium.org>
Date: Wed Nov 09 15:06:15 2016

Add chrome_modern_public_apk target

This adds an upstream equivalent to ChromeModern.apk, which is sent to
devices with Android L & M.

It differs from ChromePublic.apk only by having the native library
stored uncompressed (besides setting the minSdkVersion).

BUG= 650927 

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

[modify] https://crrev.com/be18d7c8226d8949d9b840a99b365e032697becf/chrome/android/BUILD.gn

Just find out public monochrome is not such useful as this moment, because we didn't add its package name to WebView provider list, we should add it in next Android release, since most of work are already done, I will continue landing the patches.

Filed a bug http://b/32876934 to track adding package name.

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

commit 2bad11a0781e999dffc9f2953304689b17de5e6d
Author: michaelbai <michaelbai@chromium.org>
Date: Tue Nov 15 02:04:43 2016

Build public monochrome

BUG= 650927 

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

[modify] https://crrev.com/2bad11a0781e999dffc9f2953304689b17de5e6d/chrome/android/BUILD.gn
[modify] https://crrev.com/2bad11a0781e999dffc9f2953304689b17de5e6d/chrome/android/chrome_public_apk_tmpl.gni
[add] https://crrev.com/2bad11a0781e999dffc9f2953304689b17de5e6d/chrome/android/java/AndroidManifest_monochrome.xml
[add] https://crrev.com/2bad11a0781e999dffc9f2953304689b17de5e6d/chrome/android/java/templates/BUILD.gn
[add] https://crrev.com/2bad11a0781e999dffc9f2953304689b17de5e6d/chrome/android/java/templates/MonochromeApplication.template
[add] https://crrev.com/2bad11a0781e999dffc9f2953304689b17de5e6d/chrome/android/java/templates/monochrome_application.gni
[add] https://crrev.com/2bad11a0781e999dffc9f2953304689b17de5e6d/chrome/android/monochrome_android_manifest_jinja_variables.gni

I commented on the internal bug about this (I don't think we should add it, as it has little benefit and is a security risk), and it doesn't mean having a public build is not useful.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/clank/internal/apps/+/ae8cadd25c72cc4790050b7ec2224cae5809446b

commit ae8cadd25c72cc4790050b7ec2224cae5809446b
Author: Tao Bai <michaelbai@google.com>
Date: Mon Nov 14 20:16:54 2016

It doesn't really need to be on the provider list because the place where it's useful is in non-Google builds where that list can be modified. For example, we plan on moving to using Monochrome in CopperheadOS from the current setup of having a WebView and Chromium build from the same Chromium source tree. We can just replace the existing provider and completely do away with the separate WebView.

Since we force enable the multi-process WebView, I suspect that it might also be possible for us to drop the 32-bit libraries on ARM64. I'm not sure if there's an easy way to avoid building without those now but it's probably straightforward for us to remove those ourselves from the build downstream (they weren't even automatically included until the current v55 Beta anyway, we had to figure out how to use apk_merger.py).

Multiprocess has no impact on whether you can drop the 32-bit libraries:

1) The "browser" part of WebView (the equivalent of the Chrome browser process) still runs directly inside the application and therefore the webview code must be available for all supported application ABIs.

2) Both WebView renderers, and Chrome itself (both its browser and renderer processes) explicitly run in 32-bit mode to save memory. In the Monochrome APK, the 32-bit library is the one that supports both Chrome and WebView; the 64-bit library *only* supports WebView usage and cannot be used by Chrome.

Would it be enough to make the package name configurable? (like we do with system_webview_package_name)?

To be loaded as WebView your package either has to be preinstalled in the rom (in which case you could have modified the list of packages) or have a whitelisted signature specified in the package list (for google builds this is the official release signing keys of chrome beta/dev/canary). So, renaming the package doesn't really help.

Can we still use it if we follow the instructions here:
https://sites.google.com/a/chromium.org/dev/developers/how-tos/build-instructions-android-webview

aka, 1. adb root 2. uninstall system webview 3. install our webview with correct package name

No. By deleting the copy from the system image to avoid the signing key conflict, it's no longer considered a preinstalled package and so won't be trusted unless its key is the one the package list specifies. You would have to actually push the APK *into* the system image replacing the existing one.

> 1) The "browser" part of WebView (the equivalent of the Chrome browser process) still runs directly inside the application and therefore the webview code must be available for all supported application ABIs.

Ah, that makes sense. Oh well! It will still be a lot leaner than before.

> 2) Both WebView renderers, and Chrome itself (both its browser and renderer processes) explicitly run in 32-bit mode to save memory. In the Monochrome APK, the 32-bit library is the one that supports both Chrome and WebView; the 64-bit library *only* supports WebView usage and cannot be used by Chrome.

ARM64 Chromium can be built though, even if Google isn't shipping it. I guess I'd have to deal with adapting Monochrome to use a 64-bit Chrome build for our use. I'd like to run the sandboxed WebView renderers as 64-bit too so I guess I'll also need to figure that out.

Our standalone arm64 WebView build with sandboxing enabled does already run the isolated process as 64-bit without changes to it. Maybe it works differently in Monochrome. 32-bit support is indeed being used by the apps themselves when they are 32-bit though. Oh well.

ARM64 chromium can be built, but the monochrome build config currently hardcodes the assumption that the 64-bit library is only for webview, and we don't right now have a build setting to flip this around so that the 64-bit version is chrome+webview and the 32-bit version is webview only (which is the configuration you'd want).

The standalone arm64 webview build was updated in 56.0.2891.0 to run its renderers in 32-bit mode to match monochrome: https://codereview.chromium.org/2414333002 - earlier versions of webview ran in 64-bit but this was an oversight on our part. If you want it to run in 64-bit you'll have to remove this manifest change.

FWIW, this appears to work well now. Chromium works and CTS WebView tests for armeabi-v7a and arm64-v8a both pass. 64-bit was a bit trickier to get working, but also works well:

https://github.com/CopperheadOS/chromium_patches/blob/afbb20d39c37cc1ec0b80a1c0bcdeed80f418321/0017-use-64-bit-Monochrome-processes.patch