Reland #2 of Fix monochrome not booting issue

chrome/browser/android/monochrome_entry_point.cc

Index: chrome/browser/android/monochrome_entry_point.cc
diff --git a/chrome/browser/android/monochrome_entry_point.cc b/chrome/browser/android/monochrome_entry_point.cc
index d6658bebc7d1a5d80752b170874c81fb6ab1076d..270bd19ee192f78cc44365f25705126d7147761b 100644
--- a/chrome/browser/android/monochrome_entry_point.cc
+++ b/chrome/browser/android/monochrome_entry_point.cc
@@ -7,6 +7,7 @@
 #include "base/android/library_loader/library_loader_hooks.h"
 #include "base/bind.h"
 #include "chrome/app/android/chrome_jni_onload.h"
+#include "ui/base/resource/resource_bundle_android.h"
 
 namespace {
 
@@ -23,6 +24,7 @@ bool Init() {
 // This is called by the VM when the shared library is first loaded.
 JNI_EXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved) {
   base::android::InitVM(vm);
+  ui::SetLocalePaksStoredInApk(true);

[michaelbai, 2016/10/11 21:27:44]

I still prefer not to do this, because I want to minimize the Monochrome special
code, normally if pak is uncompressed in APK, we have no reason not to read it
from APK, so

- For Chrome, if the pak is uncompressed, we just load it from APK, otherwise
from disk.
- For WebView, we only load pak from APK, otherwise fail.

We don't need special case for Monochrome here.

Also BuildConfig.java already has information about whether the PAK is
compressed or not, why we have another separated global flag
(g_locale_paks_in_apk) for almost same purpose? The not booting bug is
essentially caused by conflict of those two sources of same information, right?
What we really want is to enforce WebView only load pak from APK.

[agrieve, 2016/10/12 02:27:25]

Just to be clear - this is *not* the existing behaviour. Right now (mono)chrome
only checks disk.
This is what I had implemented in the previous patch set. It checked
BuildConfig.java
to see whether "en-US" was stored compressed, and then acted accordingly for the
requested locale.
torne pointed out that if we have a packaging bug, it would just fail gracefully
(but to our detriment), which I think is a valid concern (and applies to both
webview and monochrome)

[Torne, 2016/10/12 10:35:55]

Oh, so monochrome is currently extracting the locale paks when launched as
chrome, even though it could just map them directly from the APK? I didn't
realise this was already broken :/
Yes we do. Monochrome is packaged differently from regular chrome, on purpose,
and if that packaging doesn't work correctly we have a bug that we want to
notice as quickly as possible.
What we want to enforce is that APKs where the locales are expected to be stored
uncompressed (webview and monochrome) always load directly from the APK, so that
if we mess up the configuration it will immediately crash rather than trying to
fall back to extracting the files, which at best will waste disk space and at
worst will simply not work (in the webview case).

[michaelbai, 2016/10/12 16:39:49]

I understood you want both WebView and Chrome in monochrome are enforced to load
PAK from APK, my point is that if we have code to 
- load PAK from APK as long as PAK is not compressed( like what you did in
previous patch).
- set a flag to enforce only load PAK from APK from WebView (not here, but from
WebView) 

We can get the same goal, though Chrome in monochrome is not enforced, but if
PAK is compressed in monochrome APK, the issue is easy to be found from WebView
side. Monochrome doesn't need this code and this is not good place to put this
code, (actually monochrome has no good place to put this code now), Monochrome
should just a simple combination of WebView and Chrome at least from native
side.

   JNIEnv* env = base::android::AttachCurrentThread();
   bool ret;
   int library_process_type = base::android::GetLibraryProcessType(env);