Fix direct load from APK on Samsung devices

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

Index: base/android/java/src/org/chromium/base/library_loader/LibraryLoader.java
diff --git a/base/android/java/src/org/chromium/base/library_loader/LibraryLoader.java b/base/android/java/src/org/chromium/base/library_loader/LibraryLoader.java
index 9dc686572d0bb4a5f85b2b74c8fa5d012c6fb480..f892937ce0a7c4a9b994a460fc935d78df07f401 100644
--- a/base/android/java/src/org/chromium/base/library_loader/LibraryLoader.java
+++ b/base/android/java/src/org/chromium/base/library_loader/LibraryLoader.java
@@ -253,6 +253,9 @@ public class LibraryLoader {
                         apkFilePath = context.getApplicationInfo().sourceDir;
                         if (mProbeMapApkWithExecPermission) {
                             mMapApkWithExecPermission = Linker.checkMapExecSupport(apkFilePath);
+                        } else {
+                            // Assume map executable support on Samsung devices.
+                            mMapApkWithExecPermission = true;

[rmcilroy, 2015/05/18 15:11:48]

I was just chatting with Andrew about this.  Let's just remove all the
ProbeMapApkWithExec code from the linker now. We were only doing this to decide
when we could start load-from-apk on 32bit devices and now we have just decided
we are going to do this for only L+, so we don't really need the UMA for this
any longer.

Saying that, we should cherry-pick this change into m43 and m44 so let's land
this as-is and cherry pick it then do the bigger change after, WDYT?

[petrcermak, 2015/05/18 15:14:00]

Sounds good to me.

                         }
                         if (!mMapApkWithExecPermission && Linker.isInZipFile()) {
                             Log.w(TAG, "the no map executable support fallback will be used because"