Fix low-memory devices crashing on Chrome start up during UMA recodring

base/android/java/src/org/chromium/base/library_loader/Linker.java

Index: base/android/java/src/org/chromium/base/library_loader/Linker.java
diff --git a/base/android/java/src/org/chromium/base/library_loader/Linker.java b/base/android/java/src/org/chromium/base/library_loader/Linker.java
index cc30af4d5d21b830a562ced77c139f8f3b2ef782..ee389331b030a556d5e0a99c472fce898fd25787 100644
--- a/base/android/java/src/org/chromium/base/library_loader/Linker.java
+++ b/base/android/java/src/org/chromium/base/library_loader/Linker.java
@@ -196,6 +196,8 @@ public class Linker {
     private static boolean sRelroSharingSupported = false;
 
     // Set to true if this runs in the browser process. Disabled by initServiceProcess().
+    // TODO(petrcermak): This flag can be incorrectly set to false (even though this might run in
+    // the browser process) on low-memory devices.
     private static boolean sInBrowserProcess = true;
 
     // Becomes true to indicate this process needs to wait for a shared RELRO in
@@ -382,19 +384,6 @@ public class Linker {
     }
 
     /**
-     * Call this method to determine if the linker is running in the browser
-     * process.
-     *
-     * @return true if the linker is running in the browser process.
-     */
-    public static boolean isInBrowserProcess() {
-        synchronized (Linker.class) {
-            ensureInitializedLocked();
-            return sInBrowserProcess;
-        }
-    }
-
-    /**
      * Call this method to determine if the chromium project must load
      * the library directly from the zip file.
      */
@@ -839,6 +828,7 @@ public class Linker {
      * @return true if supported.
      */
     public static boolean checkLibraryLoadFromApkSupport(String apkFile) {
+        assert apkFile != null;

[picksi1, 2014/10/17 08:23:24]

If asserts vanish in release code (?not sure about that?) if might be worth also
returning UNKNOWN if apkFile is null.

[rmcilroy, 2014/10/17 09:12:59]

Yes asserts vanish in release mode (Java assertions  also need to be explicitly
turned on on the device on Android in order to trigger even on debug builds).
Personally I think the assert here is fine, but if you are going to add UNKNOWN
here then remove the if/else in libraryloader and state that this function
supports a null arg in the Javadoc.

[petrcermak, 2014/10/17 14:51:28]

This seems unnecessary because the method is called (from
LibraryLoader.recordBrowserProcessHistogram) only if the file name is not null.
I added a note to the javadoc that apkFile has to be "not null".

[petrcermak, 2014/10/17 14:51:28]

I would prefer returning a boolean here. If you think that the assert is
insufficient, I can make it throw a NullPointerException.

[rmcilroy, 2014/10/20 10:42:39]

I actually think the assert is unnecessary - the native code would fail with a
NPE in any case if Null is passed, which I think is clear enough as to what went
wrong.  I don't object to having the assert though, so I'm fine with this as is.

[petrcermak, 2014/10/20 15:33:22]

Acknowledged.

         synchronized (Linker.class) {
             ensureInitializedLocked();